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.