Privacy
End-to-end encrypted notes: what they protect
A plain-language look at how LiveNote’s browser-side encryption works, which threats it actually stops, and the three things it cannot protect you from.
Updated 7 min read
End-to-end encryption has a reputation for being either magical or meaningless, and both reactions come from the same cause: nobody explains which part of the system holds the key. This guide is that explanation, for LiveNote specifically.
The one-sentence version
With end-to-end encryption on, the note is encrypted in your browser before it is sent, and the server stores something it has no key to open. That is the entire idea. Everything below is detail.
Where the key lives
LiveNote encrypts note content with AES-256-GCM, a standard authenticated encryption algorithm, using a key that is generated in your browser. The encrypted text is what travels to the server and what the server stores. The decryption key never leaves your browser during normal operation, so an operator with full database access sees ciphertext.
There is a practical consequence people often miss. Because the key has to remain recoverable by you, and never by the server, end-to-end encrypted notes are tied to an account. Anonymous notes are wonderful for throwaway drafts, but there is nowhere to safely keep a key that only you can use and that survives your browser clearing its storage.
What it protects you from
- A database breach. If the server’s stored notes are ever exfiltrated, they are ciphertext without the keys. An attacker gets rows of unreadable data.
- An over-curious operator. Nobody running the service can read the note. That is a property of the design, not a promise.
- Casual exposure in transit or at rest. The content is protected everywhere except the two places it has to be readable: your screen and your browser.
- Accidental disclosure from a backup or export. Anything that copies the stored note copies the ciphertext.
What it does not protect you from
- Someone looking over your shoulder. If the note is open on your screen, it is on your screen.
- A compromised device. Malware in the browser that decrypted the note can read the note. End-to-end encryption protects data in transit and at rest, not the machine doing the decrypting.
- A shared link. Sharing an encrypted note shares the note. Anyone with the link can open it, subject to whatever else you have layered on top.
- Metadata. Encryption hides the content of a note. It does not hide the fact that a note exists, when it was created, or how often it was opened.
Passwords are a different tool
LiveNote also supports a password gate, and it is worth being precise about how it differs from encryption. A password is hashed with argon2id, a deliberately slow memory-hard function, before storage. That means the server cannot tell you the password if you forget it; it can only verify a guess. The note content itself is stored normally, and becomes readable once the gate is passed.
| Password gate | End-to-end encryption | |
|---|---|---|
| Protects the content from the server | No | Yes |
| Works without an account | Yes | No |
| Recoverable if forgotten | No, it must be reset | Yes, the key is yours |
| Stops a database breach from exposing text | No | Yes |
They are complementary rather than competing. A password gate is the friendly layer that decides who gets in; end-to-end encryption is the layer that decides what the server can ever know.
A sensible default
For most notes, the honest answer is that LiveNote’s default posture is already reasonable: a random URL nobody has, saved over HTTPS, with no third party reading it. Encryption matters most when a note is genuinely sensitive, when the audience is wider than you would like, or when you want to be certain that a future compromise of the service cannot read your old notes.
If you want to know exactly what is stored, how long it is kept, or how to delete it, the privacy policy is the place to look. It is written in plain language on purpose.