Sandboxed application can't communicate with browser extension

One of the things that we try to guarantee is that only the 1Password browser extension and the 1Password CLI can communicate with the desktop application.

We start with the assumption that anything installed by the system administrator is blessed. We're not trying to defend against a root compromise, because we all know that all bets are off once that happens. So, if the sysadmin installed the application, the BrowserHelper it will be in the expected location (which is /opt/1Password on most machines, /var/run/wrappers/bin on a NixOS machine, and within the sandbox location on a Flatpak installation). Additionally, we need the group set (onepassword and onepassword-cli, respectively), and we need setgid enabled.

With these things put together, the Linux kernel tells us exactly which executable is connected to the socket (we assume this is unforgeable without a root compromise), and we know that setgid disables LD_PRELOAD and other shenanigans that may be able to alter the the runtime.

Without these guarantees, we can only protect against rogue applications by requiring a shared secret between the desktop and any client connecting. For 1Password, that is your secret key and your account password.

With Flatpak, we cannot run any of the automated post-install scripts that set the group id and enable setgid bit. Flatpak's post-install script occurs only within the context of the sandbox and has no access to the groups we depend on. And can't create those groups, anyway. You could manually set these things, but you would have to reset them after every single update. That's the kind of breakage that is likely to lead to a lot of extra load on our CS team.

So, here's one solution I can think of. To be up front, I have no idea whether our security team would accept it, though it seems promising.

We reduce the security, allowing any application to connect and query secrets. BUT, if I haven't mis-understood the identity information that the Linux kernel provides (always possible), we will pop up a warning in 1Password identifying the full path to the executable that is trying to connect, and then allow you to decide whether to permit the connection.

Would that be an acceptable compromise?