SecureDrop began as DeadDrop, a project started by Aaron Swartz and journalist Kevin Poulsen, and after Swartz's death in 2013 it was picked up and is now maintained by the Freedom of the Press Foundation. It's open source, and it's in use at dozens of newsrooms, including major outlets that need a way for sources with sensitive information, government employees, corporate insiders, people inside institutions with something to disclose, to make contact without a metadata trail leading back to them.
The threat model is specific and it's worth stating plainly: the goal isn't just to encrypt a message in transit. It's to make sure that even if the server hosting the system, or the newsroom's network, or a single compromised laptop, is seized or subpoenaed, there's nothing on it that identifies who sent what.
Onion services only, by design
A SecureDrop instance is reachable only as a Tor onion service. There's no clearnet URL, no fallback HTTPS address a source could accidentally use. This isn't an anonymity bonus layered on top; it's the entry point. Tor's onion routing means the SecureDrop server never sees the source's IP address, and the source's ISP never sees that they connected to a news organization's tip line. Newsrooms publish their onion address on their regular website, often alongside a warning to only access it through Tor Browser, ideally from a device and network not otherwise tied to the source's identity.
PGP-encrypted email protects the message body, but the envelope, sender address, recipient address, timestamps, IP address at send time, is often visible to mail servers along the way and sometimes to the recipient's provider. A source using their personal or work email to contact a journalist has already created a durable record of contact, independent of what the message says.
Two-sided isolation: the source and the newsroom
When a source submits a message or document through the onion service, they're given a randomly generated codename, a pass phrase with no connection to their real identity, that lets them log back in later to check for a reply or submit follow-up material. No account creation, no email address, no username tied to anything outside the system.
On the newsroom side, journalists don't read submissions on the same machine that runs the server or that touches the regular internet. The recommended architecture uses three separate machines: an application server that receives submissions, a monitor server that watches for intrusion attempts, and an air-gapped viewing station, a computer that has never been and will never be connected to a network, used only to decrypt and read submissions with GPG keys that live on that machine alone. Files move to the air-gapped machine via a one-way USB transfer, specifically to avoid the viewing station ever touching a network where malware could exfiltrate what it decrypts.
| Component | Purpose |
|---|---|
| Tor onion service | Hides the source's IP address and the fact that they contacted this newsroom at all. |
| Codename login | Lets a source check for replies without any persistent identifier tying sessions together. |
| Per-submission GPG encryption | Each submission is encrypted to the newsroom's public key before it leaves the browser session. |
| Air-gapped viewing station | Decryption happens on a machine that has never touched a network, closing the exfiltration path. |
| Tails OS (recommended for sources) | An amnesic operating system that leaves no trace on the machine it was booted from, reducing what a seized device could reveal. |
What this design assumes, and what it doesn't protect against
SecureDrop's architecture assumes the server could be seized, subpoenaed, or compromised, and is built so that outcome still doesn't reveal a source's identity. What it can't do is protect a source who makes a mistake outside the system: logging in from a work computer, discussing the submission over an unencrypted channel beforehand, or being one of a small enough number of people with access to the leaked material that the leak itself narrows the suspect list regardless of how the tip was delivered. Every whistleblower guide built around SecureDrop spends as much time on operational discipline, which device, which network, who else knows, as on the tool itself, because the tool only protects the parts of the process it actually touches.
The reply mechanism, and why it's harder than it looks
A working tip system has to let a journalist ask a follow-up question without ever learning who they're asking. SecureDrop handles this by having the source generate their own codename at first contact and requiring them to remember it, since there's no password reset flow that wouldn't require some identifying recovery information. If a source loses their codename, that conversation thread is gone permanently. It's a real usability cost, and it's also the direct consequence of refusing to store anything that could re-identify a source later, including a recovery email address. Most consumer software treats "we can help you get back into your account" as a baseline feature. Here it's specifically the thing the design avoids, because a recovery path is also a re-identification path.
Newsrooms that run SecureDrop typically publish guidance alongside their onion address telling sources to use Tails, a live operating system that boots from a USB drive and leaves no trace on the host machine once it's shut down, rather than their normal, possibly monitored or logged, daily-use computer. That instruction matters more than it might seem: the strongest server-side architecture in the world doesn't help a source whose employer-issued laptop is already logging their browser history before Tor Browser ever opens.
Why the pattern matters beyond newsrooms
The core idea, minimize what's retained, assume the server will eventually be examined by someone hostile, and design so that examination reveals nothing useful, shows up anywhere a system needs to protect people who are taking a real risk to communicate: legal aid intake forms, corporate ethics hotlines with teeth, and human rights documentation projects all borrow pieces of the same architecture. It's a useful model to know even outside journalism, because it's a concrete answer to a question most software never asks: what happens to the people who used this if the server is compromised tomorrow.
Haven wasn't built as a SecureDrop replacement, and general-purpose messaging is a different threat model from anonymous source submission. But the same discipline, encrypting client-side before anything reaches a server, minimizing what the server retains, applies to journalists doing day-to-day reporting work even when the extreme isolation of an air-gapped drop box isn't warranted for the conversation at hand.