"Self-destructing" covers two quite different mechanisms. Knowing which one a tool uses tells you what it actually protects against.
Hidden versus deleted
In messaging apps, disappearing messages remove old messages from a conversation after a timer. That keeps the chat tidy and limits what's left on a lost phone, but the app can only control its own copies. Signal, which popularised the feature, said when it launched that disappearing messages are not for situations where your contact is your adversary: a recipient can always photograph the screen.
In secret-sharing tools, the stronger version deletes the stored ciphertext from the server's database after a set number of reads or at an expiry time, and the link then points at nothing. Combined with encryption in the browser, a deleted ciphertext can't be decrypted later by anyone, whatever links or keys surface afterwards.
A good tool tells you which one it does. In ProtectedShare, a burned note is deleted from the database in the same request that delivers it, not marked as hidden. Expired shares are refused on every read, and a cleanup job deletes them every 30 minutes.
Three controls: burn after reading, read limits and expiry
| Control | What it does | Good for |
|---|---|---|
| Burn after reading | Deletes the secret the first time it's opened | Passwords, recovery codes, anything one person reads once |
| Read limit | Deletes it after a set number of opens (EnvShare allows 1 to 100) | A key someone needs on a laptop and a server; a small team |
| Expiry | Deletes it at a set time, opened or not (1 hour up to 30 days) | A ceiling on how long a forgotten link stays live |
Use them together. A read limit without a short expiry leaves an unopened link alive for weeks; an expiry without a read limit lets anyone who gets the link before then read it.
Choosing the settings
Start from the job, not the defaults:
- One person, one action, such as a password or a verification code: burn after reading, and 1 hour to 1 day.
- One person, several devices, such as an API key for a laptop and a server: two or three reads, and 1 day.
- A small group, such as a deploy key for three engineers: a read count equal to the number of people, and the shortest expiry that covers everyone's time zone.
- Someone who won't see it until next week: 7 days, still one read, and a password sent separately.
When in doubt, shorter wins. A link that expires before it's used costs a minute to recreate; a link that outlives its purpose is a credential nobody is watching.
Habits that make temporary links work
- Keep the link and any password in different channels, so one leaked inbox doesn't reveal both.
- Tell the recipient what to expect: "This opens once, so copy it into your password manager."
- Check the status. My links, in the browser that created the link, shows whether it was opened, burned or expired, and lets you revoke an unopened link.
- Treat surprises as signals. If the recipient finds the link already used, someone else opened it. Change the secret.
- Don't worry about link previews with a well-built tool. Chat apps that unfurl links fetch the page without the key, and ProtectedShare's note page waits for a click before anything is read or burned.
What self-destruction doesn't do
- It doesn't stop the recipient from copying what they read.
- It doesn't protect a secret on a compromised device.
- It doesn't stop the wrong person from opening the link first; it only makes that visible.
When to use it, and when not to
Self-destructing delivery fits any secret whose value ends once it's received: a Wi-Fi password for a guest, a verification code for a family member, credentials for a contractor, an activation key moved between your own devices.
It's the wrong tool for anything that needs to be found again. Recovery codes, shared team credentials and records you're required to keep belong in a password manager or a proper document system.
To try it, create a secure note, where burn after reading is on by default, or an EnvShare link with a read limit.