Take an operator that ships bad code first. The crypto runs in JavaScript that AurionMail serves on every page load, and nothing pins that bundle: no reproducible build, no signature the browser enforces, no way for a user to verify what ran. One build that posts the master passphrase to a host they control ends it. Password strength, the 5-minute TTL, and the non-extractable CryptoKey all stop mattering. Every guarantee in the document becomes a promise about operator behaviour, and E2EE exists to remove those promises. Signed reproducible clients fix this, or published bundle hashes in a transparency log. Their security model never mentions its own delivery channel.
Ignoring that/assuming an honest build pipeline--what does a breach, an insider, or a subpoena yields later. The server holds the wrapped OpenPGP private key, the 16-byte master salt (cross-device unlock needs it), and Argon2id(password, "auth_salt_${username}") from every login. That last value verifies the same password protecting the vault, so you can grind offline at Argon2id cost, derive the master key, unwrap the PGP key, and read the mail. auth_salt_${username} is public and known before any breach, so an attacker can precompute against a named target. A random per-user salt served at login removes that discount. Proton and Bitwarden share the general ceiling, so what follows is what makes this design worse.
In addition, PGP has no forward secrecy. Combine that with a server-side mail archive and a server-side copy of the long-term private key. One password recovery at any future point then decrypts the entire history in one pass. A long-term key is only as strong as the weakest security practice across its whole lifetime, and an attacker who eventually wins reads the full back catalogue. Remote backups of the long-term key are a pattern to avoid here, but AurionMail ships that backup as a sync feature. The document reasons carefully about a 5-minute TTL on a transport blob while the real exposure window is the account's entire lifetime, applied backwards.
Rotation makes it stickier. The same post argues that people keep keys they suspect are compromised because rotating costs too much. Here the master password derives both the PGP wrapping key and the CryptPad seed, so a password change orphans CryptPad documents, and replacing the PGP key means re-establishing it with every correspondent. Two coupled rotation costs, and the document specifies neither procedure.
Coverage is the other limit. PGP over SMTP leaves envelope recipients and timestamps in clear, and it only protects mail where the other party also runs PGP. Most folks see very few encrypted emails a year, and correspondents generally resend in plaintext given any excuse. The other end decides your coverage. The security model also never says how a user authenticates a correspondent's public key, and encrypting to an attacker's key defeats everything upstream of it. Web of trust does not close that gap in practice.
Two parts of the design are correct. The cross-origin handoff keeps the seed off the network, so the server holds ciphertext it cannot open, and burn-on-read with a short TTL layers sensibly on top. One Argon2id pass feeding domain-separated HKDF labels is standard, and separate salts for auth and for the master key keep the login hash from being the vault key.
From my POV, this is client-side encryption with a trusted operator, built on a key model that competent advocates were publicly abandoning ten years ago. That property is real and it beats server-side encryption, and it requires trusting their build pipeline, their hosting, and their users' passwords. "Zero-knowledge" claims none of that trust is needed, but their security model doesn't support this claim.