What zero-knowledge means here
"Zero-knowledge" is used loosely in marketing, and it has nothing to do with the zero-knowledge proofs of cryptography research. For a note-sharing tool it should mean one specific thing: the service stores and delivers your note without ever holding what it would need to read it. Your browser encrypts the note before it's uploaded, and the key that decrypts it never reaches the server.
That doesn't mean the service knows nothing. It still sees that a note exists, how large the ciphertext is, when it was created and opened, and the network details of each request. What it can't see is the content.
The life of an encrypted note
Here is what happens in ProtectedShare's Secure Notes in the default link-key mode:
- Your browser makes a key. It draws 32 random bytes from the Web Crypto API. Nothing about the key comes from the server.
- The note is encrypted locally. The browser derives an AES-256-GCM key from those bytes with HKDF and encrypts the text. A second value, derived the same way with a different label, becomes an access token.
- Only ciphertext is uploaded. The server receives the encrypted note, a random salt and IV, the expiry and burn setting, and a SHA-256 hash of the access token. It never receives the key or the text.
- The key goes into the link, after the #. The link looks like
https://protectedshare.me/notes/…#k=…. Browsers don't send the part after#to the server when they request a page (MDN), so the key reaches the recipient through whatever channel you use, not through the service. - The recipient's browser reverses the process. It reads the key from the link, derives the same access token, and asks for the ciphertext. The server compares the token with the stored hash before releasing anything, and the browser decrypts locally.
- The row is deleted. With burn after reading on, the note is deleted from the database in the same step that releases it. Otherwise it's deleted at expiry.
If you add a password, instead of or as well as the link key, the browser first stretches the password with PBKDF2-SHA256 at 600,000 iterations, so the password doesn't leave your device either. The full construction is on the security page, and the code is open source.
What this protects you from
- A breach of the database or server. An attacker gets ciphertext and hashes, not notes.
- The operator reading notes. There's no key on the server to read them with.
- Link previews burning a note. Chat apps that unfurl links fetch the page without the part after
#, so they can't produce the access token, and the note page waits for a click.
What it doesn't protect you from
- Anyone who has the full link. The key is in the link, so the link is the secret. If the channel you send it through worries you, add a password and send that another way.
- A compromised device on either end, or a malicious browser extension that can read the page.
- Changed code. A web app delivers its JavaScript on every visit. If that code were tampered with, it could read what you type before encrypting it. Open source and the option to self-host are the mitigations.
- The recipient keeping a copy. Once the note is on their screen, they can copy it.
- Metadata. Sizes, timing and IP addresses are visible to the service and its hosting providers.
Why this model is easier to trust
Most services ask you to trust their staff, their policies and their infrastructure with your data. A zero-knowledge design shrinks that request. Instead of "we promise not to look," the claim becomes "we can't look, and here's the code that shows why."
That's a claim you can check. Read the source, watch the network requests in your browser's developer tools while you create a note, or run your own copy. A service that also tells you what its server sees, and what it can't defend against, gives you what you need to decide whether it fits the secret you're about to send.