Why client-side crypto matters

A lot of services advertise "encryption". Almost all of them mean encryption-in-transit (HTTPS) and encryption-at-rest (the database is on an encrypted disk). Both are sensible practices. Neither hides your data from the people running the service.

Where the boundary lives

Encryption protects data from someone outside the trust boundary. If the boundary is "from your laptop to the server", then HTTPS keeps it private from your ISP — but the server sees plaintext. If the boundary is "your laptop only", the server only ever sees ciphertext it cannot read.

Client-side crypto means the second boundary. Your data is encrypted before it leaves your machine, and the keys to decrypt it never exist on a server. Even if the server is hacked, subpoenaed, or quietly compromised, the operator has nothing useful to hand over.

What "client-side" means in this app

• Every encryption and decryption call runs in your browser using OpenPGP.js or Web Crypto.
• Private keys live in your browser memory only for the duration of the operation; they are never sent anywhere.
• There is no backend. The server you connect to (the static-host CDN) only delivers HTML, JS, and CSS — no API, no user accounts, no data ingestion.
• You can verify this. Open devtools → Network tab. With air-gap mode on, no outbound requests fire during any operation.

The catch

Client-side crypto pushes the trust boundary onto your machine. If your browser is compromised, or you load this app from a server that has been MITM'd, you lose. That is why this site is open source, has a Content Security Policy, and is served over HTTPS with certificate pinning. You can also clone the repo and run it locally for maximum assurance.

Convenience-versus-trust is the core tradeoff. Server-side services are easier — sync across devices, recovery flows, password reset — at the cost of trusting an operator. Client-side services are colder — lose your key, lose your data — but the operator cannot betray you.