Shh! Self-Destructing Messages
Sometimes you just can't get around sharing sensitive information over insecure channels like email, SMS, Slack, etc. All it takes is one data breach to expose a lifetime's worth of secrets — and not just yours!
To help mitigate these dangers, we've built Shh!, a free message sharing service that hides your message behind a unique, self-destructing link. Messages are encrypted and decrypted in the browser1, making it impossible for us or anyone else to read the contents without the magic link.
And once a link expires, its secrets are gone forever.
Secret Message
This message will self-destruct after X views or in 3 hours and 2 minutes, whichever comes first.
Click here to delete the message now.
How It Works
Shh! is set up to provide temporary Zero Knowledge storage of your textual secrets, meaning we can store and retrieve your (encrypted) message — while it is valid, anyway — but have no ability to decrypt and read it.
Creation
The way this works is actually pretty simple:
When you submit a new secret using the above form, a cryptographic key is generated by your browser and used to encrypt2 your plain-text message. The encrypted message, along with your view and time settings, are sent back to our server for temporary storage.
The private key, meanwhile, stays with you and is never shared with the server.
If all goes well, the server sends back a unique identifier of its own. This value is then combined with your private key (in the browser) to produce a shareable URL that looks like /shh/#/SERVERKEYyourkey
.
Retrieval
When someone lands on that URL, their browser separates out the server key and the private key. The server key is sent to the server to see if it can find the message, and if it does, it returns it (still encrypted). The private key is then used to decrypt the message in the browser so it can be displayed.
The keys are stored in the #fragment
portion of the URL because unlike the /pathname
and ?query
parts, #fragments
are only visible to the browser; they play no role in the server's request routing, and will not accidentally be recorded in system access or error logs.
Destruction
Each time a message is requested, its internal view count is incremented.3 Once that value reaches the limit, or too much time has passed, the message is deleted.
Recipients also have the option of deleting messages themselves, then and there, regardless of the limits.
Either way, without a message to display, the link will be useless4 to any future hackers who happen to stumble across it.
Zero Trust
We're cute and lovable and brilliant — and modest! — but that doesn't mean you should blindly trust Shh! actually does what we say it does.
Take a moment to verify the goings-on for yourself!
Shh! is a simple three-field web form, so that isn't actually as complicated as it might sound:
- Open your browser's Network Tools widget.5
- Reload the page.
- Submit an innocent test message, like "hello world" or "12345".
- Review the resulting request headers6 and bodies7 for any sneaky leakage.8
Enjoy the lack of trackers, analytics, and other random third-party nonsense. Haha.
Caveats
Shh! should be thought of as more a mitigation than a guarantee.
It eliminates the dangers normally associated with indefinite storage, but only after expiry, and only insofar as your share/our storage is concerned.
While a message is active, it can be viewed by anyone with the right link, and beyond that, is only as safe as the recipient chooses to keep it.
That doesn't mean you shouldn't use Shh! — less danger is better than more danger — but nothing beats a good education. ;)
---
2. Shh! currently uses AES-256-GCM for encryption, but has and will continue to evolve with the times.
3. More accurately, the view count is incremented for each request separated by ten or more seconds. This throttling proved necessary to prevent messages accidentally voiding themselves due to network jitters, sticky fingers, etc.
4. Invalid/expired links simply resolve to the default (empty) Shh! landing.
5. Firefox CTRL+SHIFT+E
; Chrome CTRL+SHIFT+I
, but then you'll have to manually click the Network
tab.
6. Every entry in the Network Tool's list will have Request Headers, used by the browser to tell the server who it is, what it wants, and how it wants it. We aren't modifying the headers in any special way, so you should only find the usual mundane browser preferences and identifiers here.
7. The POST request corresponding to your test submission will have had a "body" attached to it, containing your encrypted message and limits, and nothing else.
8. Specifically, you should not see your naked message or the key — the second half of the gibberish at the end of the resulting share URL — used to encrypt/decrypt it.