The warrant canary, and what it can and cannot say

What a warrant canary is.

A warrant canary is a signed statement that a project publishes on a schedule. It asserts things that have not happened. Its meaning is carried by the signature and by the schedule, not by the sentences alone.

The convention works by absence. While the statement keeps being renewed, signed and unchanged, readers may draw one conclusion. If a renewal is late, or a clause quietly disappears, readers draw their own conclusion. Nobody has to say anything they may be forbidden from saying.

That is the whole mechanism. It is a signal in the negative, and it is only as useful as the reader's willingness to check it on time.

What this one asserts.

There is one canary for the GuardTalk family, covering the system rather than this operating system alone. That is deliberate. A separate OS canary would let a compulsion against the system be answered with an unchanged statement here.

The family statement covers assertions of this kind:

• That no warrant, order or subpoena has been received that the project is forbidden to disclose.
• That no demand has been made to hand over signing keys, or to sign a build the project did not produce.
• That no demand has been made to add a backdoor, a weakening, or a covert update path to any component.
• That no seizure of, or compelled access to, project infrastructure has taken place.

The exact wording is the family statement's, not this page's summary of it. Read the signed text rather than this list, and treat the signed text as the only authority.

The cadence.

A canary is renewed and re-signed on a fixed cadence. The cadence is part of the mechanism: it is what tells a reader when a missing renewal has become meaningful. This project's cadence is not settled yet, so it is not stated here.

We publish no cadence figure until it is committed. Inventing one would be worse than stating none, because a reader would then start a clock that nobody is keeping.

Where the signed statement lives.

The canary is published, signed and renewed on the family site, and this page mirrors its existence rather than its content. The GuardTalk warrant canary ↗

Verify the signature against the published key fingerprint before you rely on the statement. The fingerprint itself is not yet published, and this site prints the marker instead of a value. How signature checking works here →

A mirror you reached over a hijacked path can be rewritten. Reaching the canary over the .onion mirror, and checking the signature, removes both of those worries. The mirror address is printed in the footer of every page here.

What a canary cannot tell you.

Why it matters less here than you might think.

The canary is worth publishing, and it is not the thing protecting you. The design goal is that a compelled GuardTalk can hand over very little that would help.

alphaThe verified-boot trust anchor is a custom AVB key (avb_pkmd.bin) that you generate and hold. A build we were compelled to sign is not one your device accepts. where this ends →

We hold no key that unlocks your device, and we ship no backdoor. That is not a promise to take on faith. The key model is documented, the sources are published, and the build is one you can produce yourself. The AVB key workflow → · Build it yourself →

A property of the design is worth more than a sentence on this page. The canary is published because it costs little and occasionally says something. It is not the reason your device is defensible.

Read the threat model → · Verify the build →