View-once links: why ephemeral sharing beats email
You email someone a contract. That file now lives in your Sent folder, their inbox, both providers' storage, anything that auto-archives, and every forward you can't see. You sent it once; it exists in roughly six places, indefinitely. A view-once link is the opposite bargain — one copy, one fetch, then nothing.
Email attachments are a copy machine
Email was never built to delete things. An attachment is duplicated at every hop: your client, your provider's storage, the recipient's provider, their client, and whatever backup snapshot ran overnight. None of those copies expire when you stop needing the file, and none are under your control after you hit send.
That is the wrong default for anything sensitive. The relevant privacy principle is data minimisation — hold the least data, for the shortest time, in the fewest places. It is codified in GDPR Article 5, which pairs data minimisation (data "limited to what is necessary") with storage limitation ("kept... for no longer than is necessary"). A file sitting in six durable mailboxes fails both tests before anyone has even opened it.
A link as a capability
A view-once link is a capability URL: the URL itself is the permission. No account, no login, no access list — possession of the link is authorization. It is capability-based security applied to the web. The token is unguessable and grants exactly one thing: fetch this resource, maybe once.
The tradeoff is the one the W3C's Good Practices for Capability URLs spells out: anyone holding the live link can use it. URLs leak — through browser history, sync, server logs, shoulder-surfing, and the Referer header when a page you load links onward. The link is a bearer token. Send it over a channel you trust, and don't paste it anywhere you wouldn't paste a password.
Single-use versus time-to-live
Two different controls shrink the exposure window, and they answer different questions.
- Single-use (burn): the link works exactly once, then the data is gone. Good when there is one recipient and one expected fetch. The catch is that the first fetch wins — if a link scanner, preview bot, or corporate proxy opens it before your recipient does, they get a dead link and you learn the channel was not as private as you assumed. That failure is loud, which is useful.
- Time-to-live (expiry): the link works until a deadline, then expires regardless of use. Good when you can't predict when someone will open it, or when a handful of fetches is fine. The window is bounded by the clock instead of by a counter.
You don't always have to pick one. Our short link tool expires on a time limit or a click count — whichever comes first — so you can cap both axes together. The file link tool defaults to a single download plus a short retention window, so even an untouched link ages out.
Encryption shrinks the window further
Single-use limits how many times a file is fetched. It does not, on its own, hide the file from whoever holds it during the brief moment it exists. That is where in-browser encryption comes in.
When you encrypt before upload, the file is encrypted in your browser and the server only ever receives ciphertext. The decryption key rides in the URL fragment — the part after the # — which the browser never sends to the server. The link holder can decrypt; the host cannot. That is the practical shape of end-to-end encryption: readable by sender and recipient, by no one in the middle — including us. It is also why the key belongs in the fragment and not the path: the fragment is stripped from the Referer header, while the path and query are not.
For a short string rather than a file — a password, an API key, a recovery code — the secret tool does the same thing: encrypt in the browser, put the key in the fragment, hand over a link that opens once.
Encryption protects the content, not the fact that you shared something, or with whom. The link's existence and timing are still metadata. View-once narrows the blast radius; it doesn't make the exchange invisible.
The honest threat model
What a view-once link actually buys you, stated plainly:
- It removes the durable copies. No Sent folder, no recipient mailbox, no provider backup holding the file forever.
- It bounds the window — by one use, by a clock, or both — so a leaked link is useful for a short time, not for years.
- With in-browser encryption, the host stores ciphertext it can't read, so a breach of our storage leaks nothing usable.
What it does not do: it can't protect the link in transit if you send it over an unsafe channel, it can't stop a recipient from screenshotting or re-saving what they are allowed to see, and it can't tell a human from a bot on that one allowed fetch. Pair the link with a trusted channel, assume the recipient keeps whatever they open, and keep the lifetime short. These tools are ephemeral and best-effort by design — if we don't keep it, it can't show up later, but everything downstream of the recipient is theirs.
One server-side detail worth knowing: when a browser fetches a download, the Content-Disposition response header is what tells it to save the file as an attachment and what to name it. It is a presentation hint, not a security control — it has no bearing on who can fetch the link. The single-use logic and expiry do that work.