“End-to-end encrypted” should describe a system boundary, not decorate a landing page. The FTC's 2020 Zoom case is a useful reminder: a service can use strong encryption in transit while still holding keys that let its servers read the content.
A label is not an architecture
The FTC alleged that Zoom's earlier E2EE claims did not match the commonly understood meaning because Zoom servers retained cryptographic keys for most meetings. Its explanation of the settlement is worth reading for the central lesson: naming an algorithm and naming a trust boundary are different things.
Name the two ends
For a Protected Memory, the relevant ends are the owner's unlocked browser and that same browser when it later reads the Memory. Rails stores and returns ciphertext; it is not an endpoint that decrypts it. That is more specific than saying a journal is “secure,” and it is the model described in our browser encryption architecture.
Ask where usable keys live
The browser generates a separate Master Key, uses it locally, and stores only an encrypted form of it with the service. The Vault Password derives a key in the browser to unlock that Master Key. Rails does not receive the Vault Password, the derived key, or a usable plaintext Master Key. A service should state that path plainly instead of asking readers to infer it from “AES-256.”
List the protected data
Inpages currently protects a Memory's title, rich-text body, external-link values, keepsake bytes, and inline-image bytes when its owner chooses Encrypted writing & files. It does not make every surrounding field disappear: record identifiers, timestamps, relationships, the encryption state, and hashtags can remain operational metadata. The threat model names that boundary in full.
Include the risks that remain
Client-side encryption reduces the impact of a copied database or storage volume. It does not protect a browser after malicious same-origin JavaScript runs, an unsafe extension reads an unlocked page, or malware controls the device. It also does not turn a public Memory into protected data. Honest E2EE copy must make those limits easy to find.
A practical checklist
Before relying on an E2EE claim, ask: who creates the key; who can use it; which exact fields are transformed; whether files follow the same path; what metadata remains; and what happens after a compromised endpoint or lost secret. Those six questions are a better starting point than a badge. The next case study, what a copied encrypted vault can still reveal, applies them to a breach.