mahemm

In the sense `jeffbee meant, yes.

Pretty much any memory managed language? Java, Go, Rust, Python, pretty much anything other than C/C++ these days is memory safe for security purposes.

What's the benefit of your model of authentication vs. more-common ones?

I think you're overestimating the "appreciability" of art and music. I would say most people don't have the training to understand or enjoy the majority of the most important critical works in art or music from the last 100 years, if not longer.

I'm not sure this really hits E2EE. E2EE is a claim about who cannot read your mail, so the test is whether confidentiality survives a hostile operator. This model fails that test twice, and the choice of PGP decides how bad the second failure gets.

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.

I found this to be a really informative piece about how people at the forefront of their field (in this case, AppSec) can move themselves farther with LLMs, as well as the limits to be dealt with and handled in that process.

How does this differ from e.g. S3 pre-signed URLs?

The tl;dr on why IO is important is you can just use (effectively) one program, but stuff different secrets inside them with a guarantee that no one can pull those secrets back out.

Cryptographers have proven that it's possible to use this as a primitive from which you can rebuild the rest of common cryptographic primitives (public encryption, symmetric encryption, etc). So--if it's possible to put this together it'll be a novel construction for every cryptographic primitive that also dodges some of the problems with key distribution and negotiation.

I'm surprised y'all stopped at the personal finance layer. I've been thinking for awhile that LLMs would be really effective as personal financial advisers, and this kind of hookup (plus I guess another one for investment accounts?) seems like all that's needed to bootstrap reasoning.

Would you be comfortable using this same logic to invest most of your net worth in lottery tickets/betting on black in a casino? If not, I'd be curious to hear what is different in that for you.

My FAANG employer launched a service ~6 months ago that today seems millions of DAUs. This service was 100% vibe coded. This service was created 20x faster than the median launch, and had notably fewer issues than the median launch. If AI stopped improving today, it would be a technological leap equivalent to a new high-level language paradigm for us.