A working leak-aggregator is not a single piece of software. It is a four-layer architecture — a submission system that the source uses, a processing workstation where the journalist examines what was submitted, an archive store where the verified material lives once it has been triaged, and a published surface where the resulting reporting reaches readers. The four layers carry different trust boundaries, run on different infrastructure, and have different jurisdictional postures, and the most common operational mistake among first-time leak-aggregator operators is to collapse them into one stack on one host.
This article reads the architecture honestly and names which tools fit which layer. It is for the editorial-register customer — an investigative outlet, a regional newsroom, an NGO running an anonymous tip line, a lawyer collecting whistleblower correspondence in an adversarial jurisdiction — who has decided that an anonymous-submission surface is the right addition to their publishing infrastructure and now needs the operational specifics. The tools covered: SecureDrop, GlobaLeaks, OnionShare, and the family of Hush Line-style anonymous tip lines.
The four layers
The submission layer is where the source interacts with the system. It is the layer that absolutely must not leak source identity — not via cookies, not via JavaScript fingerprinting, not via an account-creation flow, not via a TLS-only fallback that exposes IP addresses. The discipline is to operate the submission layer over Tor as a hidden service, with no JavaScript required, no account creation, no fingerprinting telemetry, and no fallback to the clearnet. The submission layer is where SecureDrop, GlobaLeaks and Hush Line each carve out their own postures.
The processing layer is where the journalist or analyst examines what the submission layer received. It is the layer where the source’s identity is most at risk of accidental disclosure: a malicious document carries an embedded tracking pixel, a PDF contains a Microsoft Office tracking GUID, an embedded macro phones home when the document is opened. The discipline that protects against this is air-gapped processing — a workstation that is not network-connected at all, that boots from a known-clean USB image (Tails, Qubes), that examines submissions only after they have been transferred from the submission system via an offline channel. SecureDrop ships its own Tails-based viewing-station spec; the discipline is the same regardless of which submission system the organisation runs.
The archive layer is where the verified material lives once it has been triaged. It is the layer where the offshore civil-liberties VPS earns its place — a VPS-4 or DS Lite operated from Iceland or Switzerland is the conservative answer for the verified-corpus storage. The archive layer is where the discipline of the migration runbook applies — full-disk encryption, manifest-signed integrity, off-site backups in a different jurisdiction.
The published layer is the public-facing surface where the resulting reporting reaches readers. It can be a clearnet site (the publication’s existing readership reaches it through a browser), a Tor hidden service for sources who want to reach the archive over Tor, or both. The hidden-service variant runs as a Tor onion service on the same VPS as the clearnet site or on a dedicated host; the discipline is straightforward Tor service operation, not the submission-system-grade hardening that the first layer requires.
SecureDrop, in honest terms
SecureDrop is the most-deployed and most-audited submission system in the editorial-register community. It originated as DeadDrop (Aaron Swartz, Kevin Poulsen, 2012); the Freedom of the Press Foundation took over development in 2013 and has maintained it through multiple security audits and many production deployments at major news organisations — the New York Times, the Washington Post, the Guardian, the International Consortium of Investigative Journalists, the Intercept, and many regional outlets carry production SecureDrop instances.
SecureDrop’s submission-system architecture is opinionated: a Tor hidden service running on a hardened Ubuntu base (the Application Server), backed by a separate Monitor Server that runs OSSEC for intrusion detection, with a journalist-side Viewing Station running Tails on dedicated hardware that is never network-connected. The hardware shape is institutional — the journalism org provides the physical machines, runs the SecureDrop install on them, and manages them via SecureDrop’s documented operational procedures. The software is open-source and the hardware list is published; the operational overhead is non-trivial but well-documented.
SecureDrop is the right answer for an institutional newsroom that has the operational capacity to run it: someone on the team owns the deployment, the org has the physical-security posture to keep the hardware secure, the journalists who handle submissions have been trained in the SecureDrop journalist workflow, the legal team has reviewed the deployment against the jurisdiction’s whistleblower-protection statute. For a smaller organisation that does not have that capacity, SecureDrop is overhead that competes with the editorial work — and the smaller organisation is better served by GlobaLeaks or Hush Line.
The SecureDrop submission system itself is not what an offshore-hosting customer hosts on OffshorePress. The submission system needs the operator’s physical control over the Application Server and the Monitor Server, which means colocated hardware in the journalism org’s facility — not a virtualised host at an offshore provider. The relationship between SecureDrop and OffshorePress is at the archive layer: the verified, triaged, and editorially-published material from a SecureDrop deployment can be hosted at an offshore civil-liberties VPS, which carries the editorial output to the wider readership.
GlobaLeaks, the simpler answer
GlobaLeaks is a lighter-weight whistleblowing platform built by the Hermes Center for Transparency and Digital Human Rights. It packages a Tor-hidden-service submission portal with a web-based recipient interface in a single application that runs on a single Ubuntu or Debian host. The deployment is a few-line install — the GlobaLeaks documentation walks through the steps in detail — and the operational overhead is closer to a Nextcloud install than to SecureDrop’s institutional commitment.
GlobaLeaks is deployed by transparency NGOs, ombudsman offices, regulators running internal whistleblowing channels, and smaller journalism organisations. It does not have SecureDrop’s air-gapped Viewing Station discipline by default; the recipient interface is web-based and the recipient examines submissions in their browser, with the implicit risk that a malicious submission may exploit the browser. The discipline that compensates is to run the recipient interface from a Tails or Qubes workstation, treat received documents as untrusted, and apply the same anti-tracking-pixel discipline as the SecureDrop Viewing Station.
For a small NGO with a regional staff and a meaningful whistleblowing channel — the kind of organisation that has decided an anonymous tip surface matters but does not have the operational capacity for SecureDrop’s institutional commitment — GlobaLeaks is the working answer. The deployment shape is compatible with an offshore VPS host: the submission portal can run on the same VPS-2 or VPS-4 as the public archive, with the Tor hidden service exposing the submission interface separately from the clearnet archive. The trade-off versus SecureDrop is the absence of the air-gapped processing discipline; the trade-off versus a do-nothing posture is everything.
OnionShare, for ad-hoc transfer
OnionShare is not a submission system. It is an ad-hoc file-transfer tool that exposes a temporary Tor hidden service for a specific transfer between two parties who have already established a side-channel for the URL. It is the right tool for a one-off interaction — a source who has reached a journalist out-of-band and now needs to transfer a specific document, an investigation that needs to share a verified corpus with a co-reporting partner organisation — and it is the wrong tool for a sustained anonymous-submission portal.
The reason OnionShare is the wrong tool for a sustained portal is that the URL is single-use and per-transfer. A source visiting an OnionShare URL once is fine; an organisation publishing a permanent OnionShare URL on its website to receive submissions is operating OnionShare as a permanent submission system, which it was not designed to be — the threat model of “URL leaks publicly” was not in scope for the design and the operational behaviour past that point is not what a journalism org wants.
OnionShare’s right place in the leak-aggregator stack is the side-channel transfer between the journalist and a known source, after the source has reached out through some prior channel. It is the operational tool for the post-first-contact phase, not the front-door tool. For an editorial-register customer building a working leak-aggregator, OnionShare belongs in the operational-discipline toolkit alongside Tails, Qubes, and gpg; it does not belong as the submission portal itself.
Hush Line and the lightweight tip-line family
Hush Line, built by Science & Design, is a newer entry in the lightweight-tip-line family. It runs as a single application that operates a tip-receipt mechanism over Tor, with the discipline that no account is created and no metadata is retained beyond what the recipient explicitly chooses to keep. It is closer in spirit to OnionShare-as-a-portal than to SecureDrop or GlobaLeaks: simpler, lower operational overhead, fewer features, and a posture that is honest about the fact that it is not the right tool for a high-volume institutional newsroom.
For an individual journalist running a personal tip line — a freelance investigative reporter who wants to make it possible for sources to reach them anonymously without committing to SecureDrop’s institutional infrastructure — Hush Line and similar lightweight tools are the right answer. The deployment shape is again compatible with a small offshore VPS: a VPS-1 or VPS-2 hosts the tip line’s hidden service alongside the journalist’s other infrastructure. The trade-off versus SecureDrop is the absence of institutional security review and the absence of the air-gapped processing discipline; the trade-off versus a personal email address as the tip-line is, again, everything.
What runs where
The offshore civil-liberties VPS earns its place at the archive and published-surface layers, not at the submission-system layer. A practical deployment for an editorial-register customer with a working leak-aggregator looks like this. The submission system runs on the journalism org’s own infrastructure (SecureDrop) or on a small dedicated host (GlobaLeaks, Hush Line) with a Tor hidden service exposing the submission portal. The processing workstation is a physical Tails-or-Qubes machine in the journalist’s office, never network-connected, that examines submissions transferred via offline media (a USB drive that has been booted from a clean image and zeroed after each use). The archive store is an offshore VPS — typically VPS-4 for a working corpus, DS Lite where the threat model includes hypervisor-side concerns — running with full-disk encryption and the manifest-signed integrity discipline from the migration runbook. The published surface is on the same VPS or a sibling, accessible by clearnet for the publication’s readership and by Tor hidden service for sources who want to reach the archive over Tor.
The key separation is that the submission system and the archive store do not share a host, and ideally do not share a jurisdiction. The submission system is in the publishing organisation’s home jurisdiction (where the journalists physically work); the archive store is offshore (where the publication’s editorial output is durably stored). The two layers communicate through the offline-media transfer at the processing workstation, not through a network link. The cost of the discipline is operational overhead; the benefit is that a compromise of one layer does not propagate to the others.
Hidden service operation on a civil-liberties VPS
The Tor hidden service that exposes the published archive over Tor is a small additional operational commitment. The discipline that matters: the onion address is generated as a v3 onion service with the operator’s chosen vanity prefix (or no vanity prefix, which is more conservative); the service’s private key is stored on the encrypted disk and never leaves the host; the Tor daemon runs in a non-root account with restricted filesystem access; the published surface served by the hidden service is the same content as the clearnet archive, with no Tor-specific differences that would create a fingerprintable surface.
For an editorial-register publication, the value of the hidden service is the source-side accessibility — sources who reach the archive over Tor leave no clearnet metadata trail, and that property is part of the publishing infrastructure rather than a feature for technically-inclined readers. The discipline of running the hidden service is documented in the Tor Project’s hidden-services manual; the operational overhead is small once the initial setup is done.
When each tool is the right answer
The decision tree is short. If the publication is an institutional newsroom with the operational capacity to run SecureDrop — has staff to manage it, has the physical-security posture for the Application Server hardware, has the journalist-training capacity for the air-gapped Viewing Station workflow, has counsel review of the deployment — SecureDrop is the answer. If the organisation is smaller, with a meaningful but lower-volume tip surface and without the institutional commitment SecureDrop demands, GlobaLeaks is the working answer. If the operator is an individual journalist or a small collective with a personal-scale tip line, Hush Line and the lightweight family are the right register. OnionShare is never the front-door tool but is the right tool for ad-hoc post-first-contact transfers.
For all four cases, the offshore civil-liberties VPS sits at the archive and published-surface layers. The submission system has its own infrastructure; the archive lives at OffshorePress.
Operational discipline
The discipline that compounds across the four layers: every component runs with full-disk encryption at rest; every credential is held by the operator and not by the hosting provider; the Tor daemon is patched against the Tor Project’s security advisories on the org’s own maintenance cadence; the air-gapped Viewing Station is rebuilt from a clean Tails or Qubes image at least quarterly; the threat-model framing for activist archives is reviewed against the deployment annually. None of these are exotic; all of them require a clear owner.
The most common failure mode in practice is not a technical compromise but a discipline lapse. The journalist examines a submission on their daily-driver laptop “just this once” because the air-gapped station is in another room. The Tor daemon does not get patched because the patching cadence has slipped. The submission portal’s hidden service is exposed via the publication’s homepage with a Read more → link to the clearnet site, defeating the source-anonymity property of the hidden service in the first place. The discipline is the work, and it is the discipline that keeps a leak-aggregator working over the years rather than for the first month.
Closing
The four-layer architecture is the working shape of a leak-aggregator for editorial-register customers. SecureDrop, GlobaLeaks, Hush Line and OnionShare each fit a different operational-capacity tier; the offshore civil-liberties VPS hosts the archive and the published surface; the operational discipline carries the deployment over time. The operator’s editorial address is the right place to start a conversation about a specific deployment; the runbook above is the generic shape, and every actual leak-aggregator is shaped by the project that runs it.
Payment in Monero, Lightning, on-chain Bitcoin, or cash by post. The brief is to make every layer of the leak-aggregator architecture match the editorial-register posture of the publishing organisation, and the four layers — submission, processing, archive, published — are the work.