NoteKillnotes that do not survive

Burn after reading, explained

Most of the risk in a private message is not who reads it today. It is who finds it in three years.

A burn-after-reading message is one that destroys itself the first time it is opened. The idea is old and the phrase is borrowed from spycraft, but the reason it matters online is duller and more useful: most of the risk in a private message is not who reads it today, it is who finds it in three years.

What "burn after reading" actually means here

You write a message. Instead of sending the text, you send a link. The first person to open that link sees the message, and in the same moment the copy on the server is deleted. Open the link again and there is nothing to open — not a hidden copy, not an archived one. The row is gone.

Two things have to be true for that to be worth anything, and most of the value is in the second:

  1. The deletion has to be real. Not hidden from a listing, not flagged as deleted, not retained "for a limited period". Deleted.
  2. The service must not have been able to read it in the first place. Otherwise burning it afterwards only limits who can read it going forward — it says nothing about what was already seen, logged or copied while it sat there.

Why the second point is the whole thing

If a message arrives at a server in readable form, then for however long it existed, the operator could read it. Deleting it later does not undo that. It also does not help against a request that arrives while the message is still waiting to be read.

Here, the message is encrypted in your browser with AES-256-GCM before anything is transmitted. The 256-bit key is generated on your device and placed after the # in the link — the fragment, which browsers do not include in HTTP requests. So the readable message never exists on this server at any point, and the burn is a second layer rather than the only one.

Burning is not what protects the contents. Encryption is. Burning limits how long the ciphertext exists and gives you a signal when the link has been used. Those are both valuable, but a "self-destructing" message that the operator could read before it self-destructed protects you against very little.

The signal you get for free

Because the link works exactly once, a dead link is information. If your recipient tells you the link was already spent, then either they opened it and forgot, or somebody else opened it first. In an ordinary messaging app, a message read by the wrong person looks exactly like a message read by the right person. Here it does not.

That is why the page a spent link shows says so plainly rather than offering a button that will fail: if it was not you, treat the contents as seen by someone else and act accordingly.

What happens technically when it burns

The read and the delete happen inside a single database transaction with the row locked. Two people clicking the same link at the same instant cannot both be served — exactly one succeeds and the other gets nothing. A one-time link that can be raced by two simultaneous readers is not one-time, and the difference only shows up under exactly the conditions where it matters.

Separately, a sweep runs every minute and removes anything past its expiry, so a message nobody ever opens still disappears on schedule rather than waiting for someone to visit. You choose the window when you write it, from ten minutes to seven days.

What it does not protect against

A screenshot. Once the recipient can read it, they can keep it. No system that shows a message to a human can prevent that, and any service claiming otherwise is selling you something.

A compromised recipient device. If their machine is not trustworthy, the message is not safe there regardless of how it arrived.

Losing the link. The key is in the link and nowhere else. If you lose it, the message is unrecoverable — by you, by the recipient, and by us. That is the same property that makes it private.

Someone who intercepts the link before the recipient uses it. They can open it first. They cannot do so invisibly, though: the recipient finds a dead link, which is the alarm.

When to use it

For anything you would not want sitting in a searchable archive: a password, a recovery code, a bank detail, a document you are sending once, a conversation that should not become a record. For anything the recipient needs repeatedly, use a tool built for storage instead — this is a handover, not a filing cabinet.

Write one

Start on the home page. No account, no email address, no cookies. Files up to 25 MB work the same way on /files, with the filename and type encrypted too, and /chat opens a room that erases itself minutes after the last person leaves.

Related: how a one-time secret link works, why the key sits after the #, and the full security architecture.