DropItLike: When Mozilla Tried to Teach Journalists OPSEC Through GitHub

Hook

In 2014, Mozilla believed that teaching journalists operational security was as simple as forking a GitHub repository. They were both right and catastrophically wrong.

Context

The Edward Snowden revelations of 2013 fundamentally changed how journalists understood digital security. Suddenly, reporters covering sensitive topics weren't just worried about protecting sources—they needed to understand threat models, encryption, secure communication channels, and operational security practices that intelligence agencies had refined over decades. The problem was acute: journalists aren't systems administrators, yet they were being targeted by nation-state adversaries with sophisticated technical capabilities.

Mozilla launched DropItLike in 2014 as part of a HOPE (Hackers On Planet Earth) conference talk, attempting to bridge this knowledge gap. Rather than building another security tool that would gather dust, they made a radical choice: package OPSEC as a GitHub repository that journalists could fork, contribute to, and learn from. The underlying philosophy was elegant—security isn't software you install, it's a practice you cultivate. By making it a repository, Mozilla encouraged users to engage with the development process itself, understanding how security tools evolve and how threats emerge. It was documentation as activism, a living knowledge base that tracked vulnerabilities through ThreatReporting.md and aggregated resources from established security organizations like the Committee to Protect Journalists and Tactical Tech.

Technical Insight

DropItLike's architecture reveals a fascinating approach to knowledge management that predates modern documentation platforms. The repository used git submodules to reference external security projects, creating a dependency graph of trusted tools without duplicating code. This meant contributors could update references to tools like Tor, GPG implementations, or secure communication platforms without maintaining forks.

The core structure relied on three components: a curated README.md serving as the entry point, ThreatReporting.md for tracking active vulnerabilities, and git submodules pointing to vetted security tools. Here's how a typical submodule reference would have been structured:

# Adding a security tool as a submodule
git submodule add https://github.com/guardianproject/ChatSecureAndroid.git tools/chatsecure
git submodule add https://github.com/guardianproject/Orbot.git tools/orbot

# The .gitmodules file would contain:
[submodule "tools/chatsecure"]
    path = tools/chatsecure
    url = https://github.com/guardianproject/ChatSecureAndroid.git
[submodule "tools/orbot"]
    path = tools/orbot
    url = https://github.com/guardianproject/Orbot.git

This approach meant users cloning the repository got pointers to specific commits of security tools, creating a snapshot of the security landscape at that moment. It's version control for threat models—you could theoretically checkout DropItLike from 2014 and see exactly which versions of which tools were considered secure at that time.

The ThreatReporting.md document implemented a lightweight vulnerability tracking system before CVE databases were accessible to non-technical users. It functioned as a markdown-based issue tracker where contributors could document emerging threats:

## Active Threats

### Heartbleed (CVE-2014-0160)
**Affected Tools:** OpenSSL-based VPNs, secure email clients
**Status:** Patches available
**Action Required:** Update all OpenSSL implementations to 1.0.1g or later
**Discussion:** #12

### Truecrypt Discontinuation
**Affected Tools:** Full disk encryption recommendations
**Status:** Investigating alternatives
**Action Required:** Evaluate VeraCrypt, LUKS
**Discussion:** #15

This structure transformed security advisories into actionable documentation that journalists could understand without parsing technical CVE descriptions. The issue number references created bidirectional links between threats and community discussion, turning the repository into a collaborative threat intelligence platform.

Mozilla's choice to use GitHub itself was pedagogical. By requiring users to understand git basics—cloning, pulling updates, reading commit history—they were subtly teaching version control concepts that matter for security. Understanding that software has versions, that updates fix vulnerabilities, and that you can audit changes through commit logs are fundamental security concepts disguised as technical skills.

Gotcha

The fatal flaw in DropItLike's design was the assumption that community maintenance would naturally sustain it. When Mozilla archived the repository, all those git submodules froze in time, pointing to 2014 versions of security tools. This isn't just inconvenient—it's actively dangerous. A journalist discovering this repository in 2024 might install decade-old encryption software with known vulnerabilities, believing they're following Mozilla's guidance. The ThreatReporting.md becomes a historical artifact rather than an early warning system, documenting threats that have been superseded by far more sophisticated attacks.

The repository's link-heavy approach also suffers from inevitable link rot. External resources referenced in documentation move, organizations rebrand, and tools get abandoned. Without active curation, a resource list becomes a graveyard of 404 errors. Even more problematic: some security practices that were considered best practices in 2014 are now known to be insufficient. The threat landscape has fundamentally changed—nation-state malware is more sophisticated, supply chain attacks are common, and mobile device security has become critical in ways that weren't understood in 2014. Following outdated security advice is often worse than following no advice at all, because it creates a false sense of security.

Verdict

Use if: You're a security researcher studying the evolution of journalist threat models from the Snowden era, or you're building a modern operational security knowledge base and want to understand what worked and failed in Mozilla's approach. The repository's structure—particularly the ThreatReporting.md pattern and submodule-based tool curation—offers valuable lessons for documentation architecture. Skip if: You need actual operational security guidance for journalism or activism work in 2024. This repository is a decade out of date and potentially dangerous to follow. Instead, use actively maintained resources like EFF's Surveillance Self-Defense (ssd.eff.org), Freedom of the Press Foundation's security training, or Security-in-a-Box from Tactical Tech. The fundamental insight Mozilla had—that security is a practice, not a product—remains true, but the specific implementations have been superseded by better-maintained projects that understand current threats.