The metadata problem nobody talks about
Most conversations about source protection focus on message content. Did the journalist encrypt it? Did the source use a burner phone? Those questions matter, but they miss something: metadata is often more dangerous than the message itself.
When a source emails a leaked document, the mail server logs record the sender, recipient, timestamp, and IP address. When they use a corporate Slack or Teams account, the message sits in a database that their employer — or a regulator — can subpoena. Even some end-to-end encrypted apps record which accounts communicated and when. That contact graph, stored somewhere outside either party's control, can be enough to identify a source before anyone reads a single word.
The question isn't just "was the content encrypted?" It's "what records prove these two people talked?"
What makes a one-time encrypted note different
A self-destructing note sidesteps some of this. The source creates a note in their browser. The plaintext never leaves their device unencrypted — the note is encrypted client-side with AES-256-GCM before it's sent to the server, and the decryption key lives in the URL fragment, which browsers deliberately exclude from server logs and HTTP referrer headers. The server stores only ciphertext it cannot read. When the journalist opens the link, the note is erased. There is no persistent record on the server of what was written.
If you want the full technical picture of why the fragment trick works — and where it doesn't — this post on the URL fragment approach is worth reading before you rely on it for anything high-stakes.
This doesn't make a source invisible. The link itself has to travel somewhere — usually via Signal, a ProtonMail message, or a secure drop submission — and that channel still has its own metadata profile. But it removes one layer of persistent exposure: the content of the tip is not sitting in an inbox, a chat log, or a cloud backup indefinitely.
A realistic workflow for passing a tip
Here's a concrete pattern that balances usability with a reasonable threat model:
- The source opens SecureNotes in a private browser window, ideally over a network that isn't tied to their identity (not their office Wi-Fi).
- They type the tip or paste the sensitive text. They set the note to self-destruct on first read, and optionally set a short expiration — say, 24 hours — so the ciphertext doesn't linger if the journalist misses it.
- They copy the generated link and send it over whatever channel they've already established with the journalist: Signal, an encrypted email thread, or a secure submission system.
- The journalist opens the link once. The note is gone.
This is not a substitute for a formal whistleblower protection system or a newsroom's SecureDrop installation. For sources facing serious legal risk, that infrastructure — with Tor routing and air-gapped servers — provides stronger guarantees. But for the far more common case — a source sharing a document with a freelance reporter, a PR professional leaking context to a columnist, a civil servant flagging a procedural problem — a one-time encrypted link is a significant improvement over email or a screenshot sent over iMessage.
The social engineering threat you can't encrypt away
Here's the thing most security guides underplay: the weakest point in this chain is usually human, not technical. A source who creates an encrypted note but then tells a colleague they've been talking to a reporter, or who uses their work laptop to access the note creation page, has handed over the exposure they were trying to avoid.
This is why the threat modeling approach matters even for journalists and sources. Before choosing a tool, ask: who is the adversary? What records do they have access to? A corporate IT team monitoring outbound traffic is a different threat than a nation-state with telco-level access. The tool choice should follow the threat, not the other way around.
For most journalist-source relationships, the adversary is a curious IT department, a litigant in discovery, or a regulator reviewing communication logs. A self-destructing note with no server-side record of the plaintext is well-suited to that scenario. It won't help if the source's employer has a keylogger on their machine.
Passcodes add one more layer for sensitive material
If the material is genuinely sensitive — the kind that could identify a source by its content alone — consider adding a passcode to the note. The journalist gets the link through one channel and the passcode through a separate one: a voice call, a Signal message, or an in-person conversation. An attacker who intercepts only the link can't open it.
The tradeoff is coordination overhead. For a quick tip this is probably unnecessary. For a document that could end someone's career or liberty, it's worth the extra step. When and how to use passcode-protected notes covers the mechanics in detail.
What this doesn't solve
Be honest about the limits. A one-time note won't protect a source who has already left a clear paper trail. It won't prevent a journalist from being compelled to reveal a source's identity in court. It won't hide the fact that the journalist and source were in contact — only the content of what was shared. And if the journalist screenshots or copies the note before it self-destructs, the content now lives somewhere else.
Operational security is a chain. A one-time encrypted note strengthens one link. The others — device hygiene, network choices, communication discipline — are still on the humans involved.
Share one secret, then forget it ever existed
If you're a journalist, a source, or anyone who needs to pass sensitive information without leaving it in an inbox forever, compose an encrypted note on SecureNotes. It takes thirty seconds, and when the recipient opens it, it's gone.
