Sending a password to a colleague, an API key to a contractor, or a bank detail to a family member is an everyday task, and most of us do it in the worst possible place: a chat thread, an email, or a screenshot. Those tools are built to keep things. That is exactly the wrong property for a secret.
Why the usual channels are the wrong ones
- Email keeps a copy indefinitely — in your sent folder, on their server, and in any backup either side runs. Revoking it later is not possible.
- Chat apps sync to every device on the account, including an old phone in a drawer and a desktop client on a shared machine.
- Screenshots outlive the conversation. They land in a camera roll, then a cloud backup, then a photo search index.
- Shared documents stay accessible until someone remembers to revoke them, which is usually never.
None of these are flaws. They are the features those products are sold on. The mismatch is that a secret needs the opposite: one delivery, then gone.
What actually makes a shared note safe
Four things matter, roughly in this order.
1. It expires by itself. The single most useful property, because it does not depend on anyone remembering. A link that dies in an hour limits the damage of a forwarded email to that hour. ShareText notes can expire after 1 hour, 24 hours, 7 days, 1 month or 3 months.
2. It can be destroyed on reading. Burn-after-read deletes the note the moment it is opened. It also tells you something: if the recipient says the link is dead, someone else opened it first. That is a tripwire no expiry setting gives you.
3. It is encrypted where the server cannot read it. End-to-end encryption means the note is encrypted in your browser before it is sent, and the key travels in the part of the URL after the #, which browsers never transmit to the server. The practical consequence: the operator holds ciphertext and cannot produce your content, for a subpoena or for an attacker with a copy of the database.
4. It needs no account from the recipient. Every account you force on someone is another record of who received what. A link that just opens leaves less behind.
A password on the link is worth adding when the channel itself is untrusted — it means an intercepted URL alone is not enough. It is a second factor for the link, not a replacement for expiry.
How to send one
- Write or paste the note at sharetext.net.
- Pick an expiry. Choose the shortest one that is realistic for when they will read it — an hour is usually plenty for a password.
- Turn on burn after reading if exactly one person should see it once.
- Add a password if you are sending the link over a channel you do not trust.
- Send the link. Send the password separately — a password in the same email as the link protects nothing.
What it does not protect against
Worth being straight about the limits.
Once someone has read the note, they have the content. Expiry deletes the copy on the server; it cannot delete what is now in their clipboard or on their screen. Burn-after-read tells you a note was opened, not who opened it. And if you paste the link into a chat that is itself being read by someone else, no setting on our side helps.
Secure sharing narrows the window and removes the permanent copy. It does not make information un-seen once it has been seen.
Related
- Security and what we can and cannot see
- Text cleaner — strip invisible characters and stray spaces before sharing
- Text compare — check what changed between two versions before you send one