Building a SecureDrop Alternative on a Tor Hidden Service
SecureDrop is the standard whistleblower submission platform used by major news organizations - it provides a Tor hidden service endpoint for sources to submit documents and communicate with journalists anonymously. Running SecureDrop requires dedicated air-gapped hardware and a specific operating system (Tails) which is operationally complex. For smaller newsrooms, independent journalists, civil society organizations, and researchers who need similar functionality without the full SecureDrop operational burden, several lighter alternatives exist that can run on a standard VPS as a Tor hidden service. This guide covers the architecture of anonymous document submission systems, lighter SecureDrop alternatives (GlobaLeaks, OnionShare, custom solutions), security considerations that differ between enterprise and lightweight deployments, and the operational practices that matter most for source protection.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
SecureDrop's complexity comes from its threat model: it assumes well-resourced adversaries (state-level actors) attempting to identify sources. Its air-gapped architecture, Tails OS requirement, and dedicated hardware defend against malware, memory forensics, and network-level attacks. For organizations with less extreme threat models (protecting sources from corporate legal departments, protecting researchers from harassment, protecting activists from non-state actors), the full SecureDrop stack is operationally disproportionate. Lightweight alternatives trade some security for operational simplicity. GlobaLeaks is the most mature lightweight alternative - it is a self-hosted web application designed specifically for anonymous document submission, actively maintained, and used by hundreds of organizations worldwide. OnionShare 2.x includes a built-in 'Receive Files' mode that creates a temporary .onion address for document receipt without any server infrastructure. Custom solutions using standard web frameworks (Django, Flask) with Tor integration require more development work but provide maximum flexibility.
GlobaLeaks Deployment Architecture
GlobaLeaks installs on Ubuntu/Debian and creates a Tor hidden service automatically during setup. Install with the official installer script: curl -s https://deb.globaleaks.org/install-globaleaks.sh | bash. The installer configures Tor, Nginx, the GlobaLeaks application, and PostgreSQL. GlobaLeaks provides a web-based admin interface for configuring submission categories, notification settings, and recipient accounts. Journalists (recipients) access received submissions through a separate .onion interface using their GlobaLeaks login. Sources access the submission interface through the source .onion address using a submission receipt code (no login required, no account). Encrypt notifications: configure GlobaLeaks to deliver submission notifications via PGP-encrypted email to journalist email addresses. Store GlobaLeaks data on an encrypted volume (LUKS) that is locked when the server is powered down. Run GlobaLeaks on a dedicated VPS used only for this purpose - no other services on the same IP.
OnionShare Receive Mode for Simple Cases
OnionShare 2.6+ running on a server in headless mode provides a simple document receipt capability without a full web application. Start OnionShare in receive mode: onionshare --receive --headless --persistent --public. This creates a persistent .onion address where anyone can upload files through Tor Browser. Files are saved to a local directory on the server. The .onion address is displayed on startup - share this address with potential sources through out-of-band channels. OnionShare is ideal for: independent journalists, researchers collecting field data, civil society organizations with modest technical resources. Limitations: no built-in journalist interface (files are just files in a directory), no source-journalist communication channel, no submission management workflow. For source communication after initial submission, establish a separate channel (encrypted email via the submission itself, a follow-up .onion communication service).
Critical Source Protection Practices
The technical platform is only part of source protection - operational practices matter equally. Key practices: (1) never open submitted documents on an internet-connected computer - use an air-gapped machine for document review, (2) sanitize documents before publication - remove metadata (EXIF, Office properties, PDF producer info) using MAT2 or ExifTool, (3) do not describe unique file characteristics publicly that could identify the source's environment, (4) verify submitted documents independently - documents can be fabricated to discredit sources and organizations, (5) protect the source communication channel - if a source contacts you via the submission platform, respond only through the same channel, (6) use a separate email address and device for source communications, (7) brief all journalists with access to submissions on source protection practices. The Freedom of the Press Foundation publishes source protection guides specifically for journalists using SecureDrop and similar platforms.
Legal and Operational Considerations
Operating a whistleblower submission platform creates legal considerations that vary by jurisdiction. In the United States, press shield laws protect journalists from being compelled to reveal sources in some states and in federal proceedings. However, the platform operator (if not a journalist) may have different protections than the journalist themselves. Consult a media law attorney before deploying a submission platform. Internationally, some jurisdictions criminalize operating platforms that receive leaked government documents regardless of journalistic context. The .onion architecture does not eliminate legal risk - it reduces the technical ability of adversaries to identify sources but does not provide legal immunity. Store the minimum data required: GlobaLeaks allows configuring short retention periods for submissions, automatically deleting submissions after a configured period.