Sandboxed application can't communicate with browser extension

"We don't care" is definitely not our stance. The synchronization model we have between client and server would not work in this case. In order to decrypt any of your data, our applications need two halves of a key. We save one half of it (the secret key) in the client applications only, and we never save the other half (your account password) in any form.

With browser integration, you only have to enter your account password, which is half of the encryption key, into the desktop application. The browser is then able to ask the desktop application for any information it needs via a local socket. But since you didn't enter your account password into the browser extension, we have to decrypt your secrets on the desktop and then safely transfer that to the browser. Since we're effectively transferring decrypted data, we had to find ways to be certain that both sides of this socket were unmodified 1Password applications. For a long time, we could only do this via some setuid root and setgid support programs that set up an encryption key via KEYCTL.

Since October, we found a way that the kernel would unforgeably communicate the identity of any application that connected to the other side of a socket. This let us drop the encryption key because now we can be sure of what is on the other side. We still do some of the same checks, but the overall effect is that we were able to enable this feature for Flatpak in late October. We still need the setuid and setgid support programs, but we no longer need to encrypt the socket data.

There are still some limitations with Snaps that prevent us from supporting browser integration, but we are thinking about ways to provide the feature there, too.