Privacy
How to share documents safely online
What actually protects a document shared by link: the risks of plain links, what passwords and encryption each stop, and when burn-after-reading is the right call.
Updated 7 min read
Sharing a document online usually means sending a link, and the link quietly becomes the whole security model. Whether that is safe depends less on the service than on a handful of decisions made in the minute before you press send: what the link grants, who else could end up holding it, and what the document costs you if it leaks.
The link is the access control
A link is not a lock; it is a capability. Whoever holds the URL holds whatever the URL grants, and URLs escape their intended audience with impressive reliability.
- Forwarding is free. A link pasted into a chat, an email, or a support ticket outlives every deletion of the message that carried it.
- Inboxes are archives. The link sits in the recipient’s sent folder, their search history, and every backup those feed, long after everyone involved has forgotten it exists.
- Link previews fetch the page. Many messengers and social apps generate a preview by requesting the URL from their own servers. If the link has no gate, the preview bot has just read your document.
- Shorteners hide the destination. A shortened link cannot be inspected before it is opened, which is exactly why people click them and exactly why attackers use them.
A password is a gate, not a vault
Password-protecting a link is the middle layer: the content stays readable to the service, but the link alone is no longer enough. Two properties matter. A well-built gate never stores the password itself, only a salted hash produced by a deliberately slow function such as argon2id or bcrypt, so the server can verify a guess but cannot tell you the password. And a forgotten password is a locked door, not a recoverable one — that is the cost of the design, and for anything sensitive it is worth paying.
The failure mode is not technical. A password sent in the same message as the link protects against nothing, because whoever intercepts one intercepts both. The password has to travel a different path than the link: a phone call, a different app, a channel the recipient already controls.
Two kinds of encryption, two different promises
Encryption labels blur together, so it helps to split them by the question each one answers. Transport encryption — the padlock in the address bar — answers “can anyone on the wire read this?” with no. Encryption at rest answers “can a stolen database be read?” with no, when the service implements it. End-to-end encryption answers the sharpest question of the three: “can the service itself read this?” with no, because the key exists only on your side of the wire.
| Transport (TLS) | Encrypted at rest | End-to-end | |
|---|---|---|---|
| Protects against a wiretap | Yes | Yes | Yes |
| Protects against a stolen database | No | Yes | Yes |
| Protects against the operator | No | No | Yes |
| Content survives a lost key | Yes | Yes | No |
That last promise comes with the most obligations. The key has to live somewhere the user controls: derived in the browser, held behind an account, or appended to the link after the hash symbol so the browser never sends it to the server. Whichever mechanism a tool picks, the rule is the same — lose the key and the content is gone, because by design there is nobody to ask. Implementations differ in how strictly they honor the bargain; LiveNote’s end-to-end mode, for example, generates the key in the browser and stores only ciphertext, which is the strict version.
What should never travel on a plain link
Some content should not sit behind anything weaker than the strongest layer available, and a few things should not go through a generic link-sharing tool at all.
- Identity documents. A photo of a passport or ID card is a complete identity-theft kit. Send it through a channel built for verified transfer, or hand it over in person.
- Financial credentials. Card numbers, bank details, and recovery codes do not belong in a shared note, however private the note is supposed to be.
- Medical and legal records. Often protected by law, with handling obligations a general-purpose tool makes no promises about.
- Live credentials. A password or API key that works right now should go one-time, or not at all.
Burn after reading, and other expiry tricks
A one-time link disables itself after the first view, which turns “forward it and see” from a risk into a non-event: the second reader finds nothing. Self-destruct timers generalize the idea — the content disappears at a set moment whether or not it was read.
The limits are worth stating plainly. Burning a link destroys the content, not the copies: a reader who screenshotted, quoted, or already copied the text keeps it. And nothing verifies that the intended person was the one who read it. One-time links are the right shape for a single secret handed to one person, and the wrong shape for a document anyone needs to reopen.
A checklist before you press send
- What does the link grant — view, edit, or discovery? Set the minimum deliberately.
- If this link ended up in a group chat, what is the worst outcome? If the answer is worse than embarrassment, add a layer.
- Does the password travel a different path than the link? The same channel means no protection.
- Does the content need to exist next week? If not, set an expiry.
- Can you say in one sentence why this channel suits this content? If not, pick another channel.
The one-sentence version
Match the protection to the worst plausible holder of the link, not the intended one. Every layer above is cheap once you know which threat you are buying protection from.