Earlier this autumn someone wrote to us through the suggestion box. They had made a delete-after-reading note, sent the link to a friend, and the friend opened it to find it was already gone. Nobody else had the link. They wanted to know what had happened.
What had happened was ordinary, and it is worth knowing about whichever tool you use: the note had been read once already, by the browser that made it.
A one-time note that was already read, by the person who wrote it
Most note tools, ShareNotes included, open your new note as soon as you save it, so you can check it and copy the link. That page load asks the server for the note, like any other visit. To a server whose only rule is "the first time someone asks for this, hand it over and delete it", the author checking their own work looks exactly like the recipient opening the link.
There are quieter versions of the same thing. A browser that restores your tabs, a phone that reloads a page you switched away from, a "recent notes" list you click to find the link again: each is a request for the note, and on the naive rule each one uses it up. The note is destroyed before it is shared, and the person you send it to gets "already read".
The tell: the link was dead when your recipient opened it, and you are sure nobody else had it. Ask whether you opened it yourself after saving, even just to copy the link. If you sent it through a chat app, also see how link previews burn notes. That is the other common cause.
Why "the first request burns it" is the wrong rule
The promise a delete-after-reading note makes is about people: the person you share it with gets to read it, and after that nobody does. "The first HTTP request" is only a stand-in for "the first reader". It works until the first request comes from someone who isn't the reader. There are two common cases: the author, and the bots that chat apps send to build link previews.
So the rule has to get more specific about who counts. The hard part is doing that without breaking the guarantee itself: if a request is wrongly treated as "not a reader", the note outlives its promise. Every exception has to fail safe.
Telling the creator apart without an account
On a site with accounts this would be easy: the note belongs to a user, and that user's visits don't count. ShareNotes has no accounts, on purpose, so it needs another way to recognise the browser that made the note.
When you save a delete-after-reading note, the server gives your browser a small cookie for that note. It is signed by the server and tied to that one note, so it can't be copied to another note, guessed, or reused if the address is later taken by someone else's note. Scripts on the page can't read it. When a request carries that cookie, the server shows the note without using it up. Every other request goes through the normal rules.
This fails the safe way. If the cookie is missing because you cleared it, opened the link on another device, or used a private window, you are treated as a reader, and the note is used up as before. A missing cookie can never make a note outlive its promise. It can only make the author count as a reader, which is what used to happen every time.
Bots, the creator, then the reader: who counts
Put together, a request for a delete-after-reading note on ShareNotes is handled in this order:
- Already used up? Then it is gone for everyone, the author included.
- The browser that made it? Shown in full, nothing used. The page tells you so, so you know it's safe to check.
- A known link-preview bot (Slack, Discord, WhatsApp, iMessage and others)? It gets the title and a placeholder, nothing used.
- Locked with a PIN for viewing? Nothing is used until the right PIN is entered.
- Anyone else is a reader and uses a read. The read that reaches the limit wipes the note. That step runs under a database lock, so it holds even when several people open the link at the same moment.
Since this week, the limit doesn't have to be one. You can let a note be read by 1, 2, 3, 5 or 10 people, for a Wi-Fi password sent to a small team or a link for a handful of students. That brought one more rule: a reader who reloads the page doesn't use a second read. Without it, a phone that reloads a tab in the background could quietly spend a read meant for someone else. The first visit leaves a cookie that works like the author's, and later visits from that browser are let through without counting. It fails safe too: without the cookie, a reload counts.
How to check a one-time link before you send it
- Open it in the browser you made it in. On ShareNotes that doesn't count, and the page says "that won't be you" at the top. If it doesn't say that, assume your visit counted.
- Don't test it on another device or in a private window. There you are a reader like anyone else.
- Paste it into chat if you like. The preview card doesn't count. Test that once with the app you actually use, though, because a new or unusual preview bot can slip through.
- Set a timer as well. A note that also expires in a day doesn't sit around forever if nobody opens it.
- Remember what it is not. Delete-after-reading limits how long a copy lingers. The note is still stored on the server until it is read, and it is not end-to-end encrypted. Long-lived or high-value secrets belong in a password manager.
You can make one by ticking Delete after reading when you generate a link and
choosing how many reads, or by sending {"maxViews": 3} to the
public API. It is free and needs no account, like everything else
on the self-destructing notes page.