A warrant canary is a statement a service publishes saying it has not received a secret order. The idea is that a government can compel silence but cannot easily compel a lie: you can be ordered not to say you received an order, but ordering you to keep publishing a false statement is a different and harder thing.

It is a clever idea. It is also widely misread, including by people publishing one. Here is what it does, what it does not, and the three properties that separate a real canary from decoration.

It proves a signature, not a fact

When you verify a canary you learn exactly one thing: this text was signed by this key and has not been altered since.

You do not learn that the statement is true. Nothing can give you that. The canary rests on a person being unwilling to sign something false, and no amount of cryptography reaches that far.

This is not a weakness to be engineered away. It is what the mechanism is: a place where a human decision becomes publicly visible. Understanding that is the difference between reading a canary correctly and treating it as a proof.

Three properties, and most canaries are missing one

It must be signed with a key published in advance. Otherwise anyone who takes the server can publish a new canary, and the canary proves only that they took the server.

It must expire. A canary without a stated renewal date cannot be read. Is it fine, or has it been silently abandoned? A reader has no way to tell, and a signal that cannot be distinguished from its own absence carries no information at all. Ours states a renewal date and a status you can read in one glance.

It must be impossible to write in advance. This is the one most often missing, and it is the one that matters most.

Think about what an adversary would want. Not to force a lie: to make the canary keep appearing on its own. If every statement could have been written a year ago, then a service under an order it cannot disclose could simply let a scheduled job publish canaries it signed before the order arrived. The canary would keep appearing, perfectly valid, meaning nothing.

The fix is to include something from the outside world that nobody could know in advance. We use the hash of the most recent Bitcoin block: public, verifiable by anyone, and unknowable until it exists. A canary containing yesterday's block hash could not have been signed last year.

Our generator refuses to publish if it cannot fetch that hash. A canary without a freshness proof looks exactly like a canary and is not one, and publishing it anyway would be worse than publishing nothing.

Why it is not automated

Ours is renewed by a person typing a command and confirming, out loud, that the statements are still true.

That is deliberate, and it is the whole design. A canary signed by a cron job survives a gag order without noticing it. The mechanism only works if the act of renewal is an act, performed by someone who could refuse.

How to read silence

If the canary is late, that is a fact about the canary. People are late.

If it is well past renewal and stays that way, read it as what it is: the statement has stopped being made. Not a coded message, nothing to decode. The statement stopped.

That is the entire vocabulary. A canary is a switch with two positions, and trying to read more into it than that is how people end up building elaborate theories out of an operator who was on holiday.

What we publish

Ours is at /canary.asc, renewed every thirty days, signed with the same PGP key that signs Skudo's mail. The transparency page shows the current state and, next to it, the three commands to check it yourself without trusting that page.

That last part is not a flourish. A page that tells you the canary is valid, with no way to verify it, is asking for exactly the trust the canary exists to make unnecessary.