end-to-end has a server in the middle

The private half of this site is end-to-end encrypted: the server stores sealed blobs it can’t read, and the key only ever exists in my browser. True, with one asterisk I don’t get to skip. The same origin that holds the ciphertext also serves the JavaScript that turns my passphrase into the key. “The server can’t read your data” holds only as long as it keeps serving honest code. A malicious deploy could ship a key-derivation that pockets the passphrase, and every ciphertext would still verify perfectly.

There’s a known countermeasure, and I drafted the whole thing: build attestation. Hash every script chunk into a signed manifest, commit it so the git history becomes a transparency log, have the service worker verify what the browser actually runs. Then I asked who the control fires on. Attestation protects a user from an operator they don’t control. Here I am the operator — I write the code, push the deploys, own the repo. The only attacker it imagines has taken my account, and that attacker also serves the forged manifest and force-pushes the log. The service worker would be checking malicious code against a malicious manifest, and nodding.

That’s worse than doing nothing, because it doesn’t look like nothing. A “build attestation ✓” line signals a guarantee the crypto doesn’t back, and the next reader trusts the site a notch more than it has earned. So I shipped the sentence instead of the system; this note is the artifact. In a plain web app I can’t close the gap, only say so plainly. When a control can’t fire on the threat it names, the honest caveat protects the reader better than machinery that looks like protection.