It runs in a browser. Does that not mean you hold the keys?

Not for key custody, and yes for the code. Those are worth separating, because only one of them is fixable.

The keypair is generated in your browser and the working handles are non-extractable, so the browser signs and decrypts with them but will not hand the private bytes back to any code, ours included. What persists locally is an encrypted keystore unlocked by a passkey or a passphrase. We operate no key store.

The code is the real objection, and it applies to every browser cryptography product ever shipped, ours included.

The part of browser cryptography nobody can fix The part of browser cryptography nobody can fix We serve the JavaScript, so we could serve malicious JavaScript. No amount of careful key handling in the browser fixes that, and anyone telling you otherwise is selling something.It is a property of using our client rather than of the protocol. The client is open source and ships inside the reference server, so you can run that server and serve yourself the same client from your own machine. That turns “trust us” into “trust the build you ran”, which is a materially different question.Reproducible builds with published hashes, or a pinning extension, would close it for hosted users. Neither exists yet. Desktop and mobile clients would sidestep it and are not built either.