Subscribe to Running With Scissors

Hacking, policy, advocacy, and the sharp end of security research. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

Check your inbox

A confirmation link has been sent to your email.

disclose.io/threats: documenting legal threats against security researchers

A structured, public archive of legal threats, cease-and-desist letters, and prosecutions against security researchers engaged in good-faith vulnerability disclosure. The evidence base for policy reform.

disclose.io/threats: documenting legal threats against security researchers

The case for safe harbor is easy to make in the abstract. Researchers help. Don't punish them for it. Most people in the industry nod along.

The case becomes concrete when you can point at specific people, on specific days, who got specific letters from specific lawyers — and whose careers, mental health, or liberty changed as a result.

That's what disclose.io/threats is for. It's a running, structured archive of legal threats, cease-and-desist letters, and prosecutions directed at security researchers engaged in good-faith vulnerability disclosure. Not rumor. Not "somebody told me." Public incidents, dated, attributed, and linked to primary sources wherever possible.

What's in the archive

Each entry captures the same five fields:

  • When — the date of the first public threat or action
  • Entity — the organization (vendor, government, platform) that made the threat
  • Researcher(s) — who was targeted, named when they consented to be named
  • Topic — what the underlying research or disclosure was about
  • Status — where the case stands now: resolved, ongoing, dropped, concluded with charges, etc.

Status fields are updated as cases progress. A "cease-and-desist sent" entry becomes a "dismissed" entry when that's what happens. An "ongoing investigation" becomes "no charges filed" or "conviction, appealing." The archive tries to tell the truth of how each one ended, because the ending is what determines whether a case becomes a deterrent or a cautionary tale.

Why this exists

Every researcher who's been in this work more than a few years has a story. Some of those stories are dinner-table stories. Others aren't told at all — because when the threat is still active, or the NDA is still in force, or the settlement includes a non-disparagement clause, the researcher cannot tell it.

The archive exists for three reasons.

First, as an evidence base for policy work. When legislators, regulators, and courts are asked to consider whether good-faith security research deserves protection, "it's a real problem" is a weaker argument than "here are thirty-seven documented cases in the last ten years." The archive gives anyone working on CFAA reform, safe harbor legislation, or international coordinated vulnerability disclosure frameworks a primary source they can cite without having to rebuild it from scratch.

Second, as a sanity check for researchers. Before you commit to a disclosure path with an organization you don't know, searching the archive is a reasonable thing to do. If the organization has a history of lawyering up in response to reports, you'll find it. If they don't, the absence is also informative. Not every threat goes in — we only include cases that became public in some form — but the pattern is usually visible once one case leaks.

Third, as memory. These cases have a tendency to fade. The journalist moves on, the court docket goes behind a paywall, the original tweet gets deleted. Without a structured archive, the evidence base for a systemic problem gets eaten by the normal decay of internet sources. The archive is, in part, a hedge against that.

The relationship to the rest of the work

The archive is one corner of a larger picture that includes the policy framework, the maturity model that underpins the directory, and the policy templates that organizations use to build safe-harbor-compliant VDPs.

A program at Level 3 or higher on the maturity model — meaning its policy includes at least partial safe harbor — is, by definition, one that has committed not to become an entry in the threats archive. That's not a decorative promise. Programs that made that commitment and then broke it have ended up in the archive, and their reputations reflect that. The archive is, in that sense, the enforcement mechanism for the rest of the system. Not legally binding. Reputationally binding.

We would like the archive to shrink in real terms — meaning fewer new cases per year, not fewer cases because we stopped documenting. That is a long-term goal, and the maturity model + safe harbor adoption + ongoing legislative reform is the path to it.

Credit where it's due

This work didn't start with disclose.io. The historical record was started — and is still maintained — by Brian "Jericho" Martin at attrition.org's legal threats archive, which has been documenting cease-and-desist letters, criminal cases, and bogus prosecutions against researchers for the better part of two decades. A large portion of the historical entries in disclose.io/threats were ported over with Jericho's permission, and the attrition.org archive continues to run in parallel. Hat tip, sincerely.

The day-to-day maintenance of the disclose.io archive is carried by sickcodes, who has done the unglamorous work of triaging issues, chasing primary sources, and keeping the data structured. The full credit list lives on the contributors page — that's the canonical record of who has actually built and rebuilt this thing over the years. Thank you all.

What you can do

If you know of a case that's not in the archive, the disclose/research-threats repository is where contributions go. The "Improve this page" link on disclose.io/threats takes you straight to the edit view on GitHub. Include a primary-source link (news coverage, court filing, organization statement) and a one-paragraph summary.

If you're currently facing a threat, the archive is not the first thing to do. The first things to do are: engage a lawyer (EFF, the SRLDF, your bug bounty platform's dispute process if you reported through one, or private counsel), document everything, and stop talking publicly about the technical details until you have representation. The archive comes later, and only if you choose to have it be part of the public record.

If you're a program owner reading this and thinking about how to make sure your program never ends up here — that is the right instinct, and the maturity model is designed to help you get there incrementally. Every level up is a step away from the failure modes the archive documents.

This is the uncomfortable part of the work. Someone has to do it, and we do.