Why the decryption key lives in the URL fragment, and where that trick breaks down
SecureNotes keeps the decryption key in the URL fragment so it never reaches the server. Here's the exact m...
Notes are encrypted client-side before they ever touch our servers. Only the link holder can decrypt them - we can't, and neither can anyone reading the database.
One read and the ciphertext is wiped from disk. No backups, no shadow copies.
No analytics, no IP retention, no telemetry on your message body. Ever.
Add a passcode the recipient must know. Out-of-band trust, in two channels.
From one hour to thirty days. After that the note is gone, with or without a read.
Optional email pings the moment your link is opened - so you know your message reached the right person, and exactly when. No more "did you get it?" follow-ups.
Type or paste the secret. Set a lifetime, view limit, optional passcode.
AES-256-GCM runs in your browser. The key never leaves the URL fragment.
Share the one-time link via WhatsApp, email, or however you prefer.
Message self-destructs after being read or when time expires.
A short, honest list. No marketing claims we can't defend.
Authenticated encryption. The decryption key lives in the URL fragment, never in our database.
HTTPS-only, HSTS, strict CSP. CSRF tokens on every write, rate limits on every read.
Expired ciphertext is hard-deleted. We can't restore it. We don't want to.
No login, no profile, no third-party trackers on note pages. There's nothing to leak.
The full source is on GitHub. Read it, fork it, run it on your own server.
SecureNotes keeps the decryption key in the URL fragment so it never reaches the server. Here's the exact m...
Adding a passcode to a self-destructing note sounds like extra security. Sometimes it is. Sometimes it just...
When a contractor's engagement ends, the secrets they touched don't expire automatically. Here's how to aud...