A warrant canary is a published statement asserting that an operator has not received a specific kind of legal process — typically a National Security Letter in the US context. If the statement disappears or stops being updated, a careful observer can infer that something has changed. The logic is that compelled silence is possible under NSLs, but compelled lying (forcing someone to reassert a false statement) is considered much harder legally. The legal theory is untested in court, and honest lawyers will tell you so. But the signaling value, done well, is real.

What the Statement Should Claim

Keep it short and negative. A typical statement:

As of [DATE], [OPERATOR] has not:
  - received any National Security Letter
  - received any gag order
  - received any secret subpoena
  - been compelled to modify our system to allow surveillance
  - been compelled to hand over cryptographic keys

Each bullet is a distinct claim. When any bullet becomes false, that bullet is removed from the next publication. The absence is the signal.

Don't over-claim. Don't include things you have no standing to know ("no government anywhere has investigated us"). Don't include things a compelled party would still be forced to reassert ("we have never had a bug"). Stick to legal processes that NSL-style gag orders cover.

Freshness Proofs

A signed statement from three months ago proves nothing about today. You need to bind each publication to a point in time that couldn't have been predicted. Two conventions are common:

  • Bitcoin block hash — include the latest block's hash and height. This proves the statement was written after that block existed. Anyone can verify it on a block explorer.
  • News headlines — the top three headlines from Reuters, the BBC, and a specific newspaper, each quoted verbatim. This works without crypto literacy in the audience, but is fuzzier to verify mechanically.

Include both. It costs nothing and gives readers two independent checks.

Signing and Frequency

Sign every publication with the same PGP key you use for your public identity. Publish on a predictable cadence — monthly is common, weekly for high-stakes services — and commit to that cadence in the canary itself ("this canary is updated on the first Monday of each month").

  • Use a YubiKey or air-gapped signing workflow, not a hot key that automation could misuse.
  • Publish to at least two locations: your main site and a mirror (Git repository, IPFS, an archive.org snapshot). Redundancy here is important — if only one copy exists and it "breaks," the signal becomes ambiguous.
  • Keep old canaries online forever. The history is part of the proof.
gpg --clearsign canary-2026-02-01.txt
# publishes canary-2026-02-01.txt.asc

Think About the Ending on Day One

The hardest question about a canary is: what do you do when the moment actually arrives? If you've thought carefully, your answer is already baked in. Some operators choose to simply stop publishing — the canary dies. Others remove specific bullets while leaving the rest. Others take the whole site down. None of these is obviously correct; they depend on the jurisdiction, the legal advice you've received, and what the canary was supposed to signal.

Write down in advance — and share with one trusted attorney — what the stopping rule is. If you're ever in the situation where you need to act on it, you'll be stressed, possibly legally constrained in ways I can't anticipate, and absolutely not in a state to design a response from scratch.

A note on theater: a canary you never planned to let lapse is worse than no canary at all. Users build a trust model on it. Running one is a long commitment. Take it seriously, or don't run one.