Why the new-device approval gate is gone

Until late September, signing in on a new device required approval from a device you had already trusted. We removed that requirement, and the reasoning is worth writing down.

The gate did not do what it looked like it did. The login password is also the input for deriving your encryption keys: the same passphrase passes the auth check and derives the key-encryption key. If the password check succeeds, the keys can be derived on that device. A second device vouching for the first never changed whether someone holding the password could decrypt your data. It added a step without adding a boundary.

It also failed in ordinary use. "Trusted" was keyed to a per-browser visitor id kept in localStorage, and that id is scoped to the origin. Sign up at one address and later open the site at another, clear site data, or use a private window, and the same person looks like a brand-new device — with no self-service way to approve it. That is a lockout, not a control.

The flow now has one condition for receiving key material: a correct password. The devices page stays, but as visibility rather than a gate — it lists sessions, sign-in history and new-device markers, and lets you revoke sessions. A "trusted" label is display-only and blocks nothing.

What did not change: plaintext keys never leave the browser, the server holds only ciphertext and derivation parameters, and key material is handed over only after password verification.

The lesson: a control that neither changes an attacker's capability nor survives normal use is not a control. It is friction.