Plenty of tools promise private notes, and the differences that matter are mostly invisible in the interface. Here are the questions worth asking before you trust one with a password or a private message. Most can be answered from a tool's security page, its privacy policy or its source code.
1. Where does encryption happen?
It should happen in your browser, before anything is uploaded. If a service encrypts after receiving your note ("encrypted at rest"), it had the plaintext first and it holds the keys. Client-side vs server-side encryption explains the difference.
A quick test: open your browser's developer tools, create a note, and look at the network request. You should see unreadable ciphertext, not your text.
2. What does the password actually do?
"Password-protected" means very different things. In some products the password unlocks a screen while the note sits readable on the server. In others the password is turned into the encryption key, so without it nobody, the service included, can decrypt the note.
You want the second kind, with the password stretched by a deliberately slow key-derivation function so each guess is expensive. ProtectedShare stretches note passwords with PBKDF2-SHA256 at 600,000 iterations, the figure the OWASP Password Storage Cheat Sheet recommends. Even so, a password-only note is only as strong as its password, so use a long generated one.
3. Where does the key live?
There are two common designs, and a good tool offers both:
- The key in the link. A random key goes after the
#in the link. Browsers don't send that part to the server (MDN), so the service never sees it. The link itself becomes the secret: anyone with the whole link can open the note. - A password sent separately. The link alone opens nothing; the recipient also needs a password you send another way.
ProtectedShare's Secure Notes supports a link key, a password, or both. Both together is the strongest option: a leaked link opens nothing without the password.
Be wary of claims that the key "never leaves your device." If you're sharing a note, the key has to reach the recipient somehow. The honest version is that it never reaches the server.
4. Is deletion real?
"Self-destructing" should mean the stored ciphertext is deleted from the database, not hidden from view. Look for a clear statement of when data is deleted (on first read, after a read limit, at expiry) and how quickly expired data is purged. Self-destructing messages explained covers the difference.
Check how the tool handles link previews too. Messaging apps fetch links to build previews, and a careless tool lets that fetch burn the note before your recipient sees it.
5. Does it need an account?
For one-off sharing, an account mostly adds data to collect and another password to manage. A tool without signup can still encrypt locally, enforce expiry and keep the server blind to content. What it gives up is a history that follows you across devices: ProtectedShare keeps your list of shares in My links, in the browser that created them, which is a deliberate trade.
No account also means the recipient never has to sign up, which often decides whether people use the secure option at all or fall back to pasting into chat.
6. What does it track?
"Zero tracking" is a strong claim and rarely literally true: web servers and hosting providers see IP addresses and request times, and many sites run analytics. Look for specifics instead:
- Does the site load analytics, and is it kept off the pages where notes are created and opened?
- Does the app set cookies of its own?
- What do the server logs contain?
For transparency, here is ProtectedShare's answer. The hosted site may load Google Analytics on its general pages when the operator enables it; it never loads on pages that open or hold a share, and page views report the path only. The app sets no cookies of its own, though Google Analytics sets its own when it's on. The privacy page says whether analytics is enabled, and the security page lists what the server sees.
7. Can you verify any of it?
Claims are cheap. Open-source code lets anyone check where encryption happens and what's sent. A published security model that also says what it doesn't protect against is a good sign. The option to self-host removes the need to trust the operator at all.
8. Does it fit the job?
Finally, the practical details. It should work well on a phone, make expiry and read limits easy to set, and show the recipient clearly what happened, including whether a note was already opened. Tools that are awkward don't get used, and the secret ends up in a chat message instead.
Quick checklist
| Question | A good answer |
|---|---|
| Where is it encrypted? | In the browser, before upload |
| What does the password do? | Derives the key, through a slow key-derivation function |
| Where is the key? | In the link fragment or with you, never on the server |
| What happens when it's read? | The ciphertext is deleted, not hidden |
| Account needed? | Not for sharing |
| Tracking? | Stated specifically, and none on pages that open notes |
| Can you verify it? | Open source, with a documented threat model |