Was ist ein Warrant Canary, und warum ist er wichtig?

Ein Warrant Canary ist eine regelmäßig veröffentlichte, PGP-signierte Erklärung, dass ein Dienstanbieter bestimmte Arten von Rechtsverfahren nicht erhalten hat — am häufigsten einen National Security Letter, eine Schweigeverfügung oder einen Massenüberwachungsbefehl. Der Canary läuft weiter, bis er stoppt. Das Ausbleiben des nächsten geplanten Canary ist das Signal, dass sich etwas geändert hat. Diese Seite erklärt den Mechanismus, führt durch die PGP-Verifizierung und listet die Anbieter auf, die 2026 einen pflegen.

Aktualisiert 2026-05-03 · Autor: BitVPS Engineering

Den Live-BitVPS-Canary ansehen → So verifizieren Sie einen Canary

Mechanismus

Wie ein Warrant Canary funktioniert — die rechtliche Logik

Der Warrant Canary beruht auf einer bestimmten Asymmetrie in der Doktrin zur erzwungenen Aussage. Viele Überwachungsgesetze – 18 USC §2709 in den Vereinigten Staaten (die Befugnis für National Security Letters); analoge Bestimmungen im britischen Investigatory Powers Act 2016 (§133 Geheimhaltung); Entsprechungen in anderen 14-Eyes-Rechtsordnungen – enthalten Geheimhaltungsklauseln, die den Empfänger einer Anordnung daran hindern, darüber zu sprechen. Diese Klauseln erzwingen Schweigen. Sie zwingen den Empfänger in den meisten Rechtsordnungen nicht dazu, aktiv eine falsche bejahende Aussage zu machen.

Genau diese Unterscheidung nutzt der Canary aus. Ein Anbieter veröffentlicht in festem Takt – wöchentlich, monatlich, vierteljährlich – die Aussage "Wir haben bis [Datum] keinen NSL erhalten". Solange die Aussage wahr bleibt, wird die Veröffentlichung fortgesetzt. Erhält der Anbieter eine Anordnung, darf er das nicht direkt sagen (Maulkorb-Anordnung). Aber er kann aufhören, die bejahende Aussage zu veröffentlichen. Der nächste planmäßige Canary erscheint entweder nicht, oder er erscheint mit entfernter relevanter Klausel, oder er erscheint mit anderem Wortlaut. Diese Abwesenheit – diese Änderung – ist eine Information, die die Maulkorb-Anordnung nicht unterdrücken kann.

Der BitVPS-Canary, veröffentlicht unter /canary/, folgt diesem Muster. Jeden Montag signieren wir eine Erklärung neu, die die Woche bis zum vorherigen Sonntag abdeckt. Die signierte Erklärung listet auf: erhaltene NSLs (Ziel: null), erhaltene Maulkorb-Anordnungen (Ziel: null), erhaltene Vorratsdatenspeicherungs-Anordnungen (Ziel: null), Anordnungszahlen pro Rechtsordnung (St. Kitts und Nevis, Island, Niederlande, Rumänien, Schweiz), erhaltene vs. bearbeitete DMCA-Mitteilungen sowie erhaltene vs. bearbeitete Missbrauchsbeschwerden. Fünf der sechs Zahlen sollten in einer normalen Woche null sein; die Missbrauchs- und DMCA-Zahlen sind absichtlich von null verschieden (wir erhalten Missbrauchsbeschwerden, und wir veröffentlichen, wie viele).

Der Takt ist entscheidend. Ein einmal jährlich veröffentlichter Canary trägt weniger Signal als ein wöchentlich veröffentlichter – die Verzögerung zwischen Zwang und dem Bemerken durch den Kunden ist das Aktualitätsfenster. Wöchentliche Canaries reduzieren dieses Fenster auf sieben Tage; tägliche Canaries (selten, da sie eine Schlüsselverwaltung im großen Maßstab erfordern) reduzieren es auf vierundzwanzig Stunden. Vierteljährliche Canaries lassen ein Dreimonatsfenster, in dem ein Anbieter kompromittiert sein könnte, bevor ein externer Beobachter etwas bemerkt.

PGP-Verifizierung

Verifizierung eines PGP-signierten Canary — vier Schritte

Ein Canary, der nicht kryptographisch signiert ist, ist Theater. Die Verifizierung dauert vier Schritte und etwa neunzig Sekunden. Das folgende Beispiel verwendet den BitVPS-Canary; dasselbe Verfahren funktioniert für jeden Anbieter, der einen PGP-signierten Canary veröffentlicht.

Schritt 1 – Holen Sie den öffentlichen Schlüssel vom Anbieter. BitVPS veröffentlicht den öffentlichen PGP-Schlüssel unter /pgp/. Der Schlüssel-Fingerabdruck ist auf mehreren Seiten der Website dokumentiert (Über uns, Canary, PGP, Footer), sodass ein Manipulationsversuch auf einer einzelnen Seite erkennbar ist. Gleichen Sie den Fingerabdruck mit mehreren Quellen ab – archive.org-Snapshots, die Wayback Machine, Drittanbieter-PGP-Keyserver –, bevor Sie ihm vertrauen.

curl -O https://bitvps.io/pgp/bitvps-pubkey.asc
gpg --show-keys bitvps-pubkey.asc

Schritt 2 – Importieren Sie den Schlüssel. Importieren Sie ihn in Ihren lokalen GnuPG-Schlüsselbund. Der Schlüssel verbleibt in Ihrem lokalen Speicher – kein Upload erforderlich, kein Vertrauen in Dritte nötig.

gpg --import bitvps-pubkey.asc

Schritt 3 – Laden Sie den signierten Canary-Text herunter. Der Canary unter /canary/ ist gerendertes HTML, aber die zugrunde liegende signierte Datei ist auch als clearsigned .asc verfügbar – sichtbar am unteren Rand der Canary-Seite oder direkt über den Storage-Pfad. Speichern Sie sie für dieses Beispiel als canary.asc in Ihrem Arbeitsverzeichnis.

curl -O https://bitvps.io/canary/latest.asc

Schritt 4 – Verifizieren Sie die Signatur. Führen Sie gpg --verify gegen die .asc-Datei aus. Eine Zeile "Good signature" bestätigt zwei Dinge: Der Canary wurde vom Inhaber des importierten Schlüssels signiert, UND der Canary-Text wurde seit der Signierung nicht verändert. Eine fehlgeschlagene Verifizierung bedeutet, dass die Datei geändert wurde, die Signatur ungültig ist oder der Schlüssel nicht passt – behandeln Sie den Canary als nicht vertrauenswürdig und untersuchen Sie weiter.

gpg --verify canary.asc

# expected:
# gpg: Good signature from "BitVPS Ltd. <>"
# gpg: Primary key fingerprint: 4DCF 5D6D 10AF F2AA 47E2  070E A62A EDAF 647E E3E6

Falls Sie GnuPG noch nie verwendet haben, installieren Sie es zuerst: `apt install gnupg2` unter Debian-basiertem Linux, `brew install gnupg` unter macOS oder laden Sie GPG4Win unter Windows herunter. Der Verifizierungsschritt selbst ist auf jeder Plattform gleich.

Aktive Canaries

Hoster und Organisationen die einen Warrant Canary pflegen

Kurze Liste, verifizierbar. Wir haben historische Beispiele (Apple 2013–2014, Reddit 2014–2016) als Kontext aufgenommen — sie sind als Fallstudien nützlich, wie ein Canary Veränderungen signalisiert. Senden Sie uns Ergänzungen über /panel/?section=support, wenn Sie einen öffentlichen Canary pflegen, der hier nicht aufgeführt ist.

Anbieter / Projekt	Takt	Erstmals veröffentlicht	Status	Hinweise
rsync.net	Quarterly, PGP-signed	2014	Maintained	One of the earliest commercial canaries. Includes Bitcoin block-hash as a freshness anchor.
BitVPS	Weekly, PGP-signed (every Monday)	2024	Maintained	Per-jurisdiction order counts (KN, IS, NL, RO, CH) plus DMCA, abuse, NSL and gag-order statements.
Bahnhof (transparency report)	Annual transparency report (not a canary in the strict sense)	2014	Active transparency reporting	Swedish ISP. Publishes detailed transparency stats; the canary-style attestations are scattered through the integrity page rather than a single signed document.
The Tor Project	Annual	2014	Maintained	Re-affirmed annually. One of the longest-running organisational canaries.
Apple (historical)	Removed in 2014 — historical example, not current	2013	Removed (2014) — historical	Apple's November 2013 transparency report contained the canonical "Apple has never received an order under Section 215" canary statement. The line was conspicuously absent from the September 2014 report. Apple has not commented publicly on the change.
Reddit (historical)	Removed in 2016 — historical example, not current	2014	Removed (2016) — historical	Reddit's 2014 transparency report carried a National Security Letter canary. The 2015 report removed the language. The administrator who maintained the canary commented publicly that he could not say more.

Wir halten diese Liste bewusst kurz. Eine lange Wunschliste verwässert das Signal — der Wert eines Canary besteht darin, dass er verifizierbar ist, und Verifizierung im großen Maßstab ist teuer. Wir aktualisieren die Liste, wenn wir sie ändern; das dateModified-Feld auf dieser Seite spiegelt den letzten Verifizierungsdurchlauf wider.

Ehrlicher Abschnitt

Was bedeutet ein fehlender Canary tatsächlich?

Ehrliche Antwort: weniger als der Marketingtext impliziert. Die häufigste Ursache für einen verpassten Canary im vergangenen Jahrzehnt war nicht der Erhalt eines National Security Letter — es war administrative Unachtsamkeit. Der verantwortliche Ingenieur war im Urlaub, der Cron-Job traf eine Anmeldedatenrotation, das DNS für die Canary-Subdomain lief ab, das Unternehmen vergaß es. Eine einzelne verpasste Erneuerung ist schwaches Signal bestenfalls.

Was ein schwaches Signal in ein starkes verwandelt, ist Bestätigung. Achten Sie auf:

Ein Canary, der seine planmäßige Erneuerung verpasst und taucht anschließend mit inhaltlich verändertem Wortlaut wieder auf (eine Klausel entfernt, die Anzahl der Jurisdiktionen geändert, der Geltungsbereich eingegrenzt).
Ein Ausbleiben des Canary, das mit einer öffentlichen Berichterstattung über ein rechtliches Verfahren gegen den Anbieter zusammenfällt.
Ein Wechsel des PGP-Schlüssels, der mit der Unterbrechung des Canary einhergeht — insbesondere, wenn der neue Schlüssel ohne den Abgleich des Fingerabdrucks über mehrere unabhängige Quellen veröffentlicht wurde, wie ihn der ursprüngliche Schlüssel hatte.
Organisatorisches Schweigen — keine öffentliche Erklärung zur Unterbrechung, keine Stellungnahme in sozialen Medien, keine Antwort auf direkte Kundenanfragen.
Plötzliche Nichterreichbarkeit der Canary-URL selbst, vor allem, wenn auch zwischengespeicherte Versionen auf archive.org entfernt werden.

Apples Entfernung des Canary im Jahr 2014 ist die klassische Fallstudie. Der Transparenzbericht vom September 2013 enthielt den Satz "Apple has never received an order under Section 215 of the USA Patriot Act." Der Transparenzbericht vom September 2014 enthielt ihn nicht. Apple gab keine öffentliche Erklärung zu dieser Änderung ab. Datenschutzforscher (Christopher Soghoian, damals bei der ACLU; Glenn Greenwald bei The Intercept) wiesen innerhalb weniger Tage auf das Fehlen hin. Das Signal war zunächst schwach — es hätte eine redaktionelle Änderung sein können — doch das Fehlen blieb über die folgenden Berichte hinweg bestehen, und Apples Chefjustiziar bestätigte die Canary-Aussage auf direkte Nachfrage anschließend nicht erneut. Zwei Jahre später lautete die übereinstimmende Deutung in der Datenschutz-Forschungsgemeinschaft, dass Apple eine Anordnung nach Section 215 erhalten hatte. Apple hat dies nie bestätigt oder dementiert.

Die richtige Deutung eines ausgebliebenen Canary ist "weiter nachforschen", nicht "dem Anbieter wurde eine Anordnung zugestellt". Canaries sind ein Beleg in Abwesenheit von Täuschung, kein Beweis in deren Anwesenheit.

Grenzen

Einschränkungen von Canaries als Signal

Drei ehrliche Grenzen, die Sie abwägen sollten, bevor Sie einen Canary als kryptographischen Beweis für die Integrität des Anbieters behandeln.

1. Die rechtliche Konstruktion hängt von einer Gesetzeslücke ab. Der Canary nutzt die Doktrin aus, dass Schweigeverfügungen zum Schweigen zwingen, nicht aber zu einer aktiven Falschaussage. Diese Doktrin wurde nicht für jedes Überwachungsgesetz in jeder Jurisdiktion abschließend geprüft. Die Stanford Law Review und andere Rechtswissenschaftler haben für beide Seiten argumentiert. Ein entschlossener Staatsanwalt könnte plausibel geltend machen, dass das erzwungene Fortführen der aktiven Veröffentlichung von "wir haben nichts erhalten" selbst Teil einer Geheimhaltungspflicht ist und dass das Einstellen der Veröffentlichung einen Verstoß gegen die Schweigeverfügung darstellt. Die rechtliche Konstruktion hat sich in der veröffentlichten US-Rechtsprechung bislang bewährt, ist aber nicht bis zu einer endgültigen Klärung ausgefochten worden. In anderen Jurisdiktionen ist sie noch weniger erprobt.

2. Unsignierte Canaries sind nutzlos. Ein Canary, der nicht mit einem überprüfbaren PGP-Schlüssel signiert ist — oder der einen Schlüssel verwendet, dessen Fingerabdruck nicht gegen mehrere unabhängige Quellen abgeglichen werden kann — ist reines Theater. Ein Angreifer, der die Website des Anbieters kontrolliert, kann einen gefälschten "alles in Ordnung"-Canary einschleusen, und es gibt keine Möglichkeit, die Manipulation zu erkennen. Die PGP-Signatur ist das, was den Canary tragfähig macht. Unsignierter Text ist kein Canary, ganz gleich, was er aussagt. Prüfen Sie, bevor Sie vertrauen.

3. Ausgelaufene Canaries sind mehrdeutig. Wenn ein Canary nicht mehr erneuert wird, hängt die Deutung davon ab, was sonst noch geschieht. Ein ausgelaufener Canary plus organisatorisches Schweigen plus ein Schlüsselwechsel ist ein starkes Signal. Ein ausgelaufener Canary allein ist schwach — er könnte bedeuten, dass der zuständige Techniker im Urlaub ist. Ein Canary, der nie begonnen wurde, ist überhaupt kein Signal. Die Last der Auflösung dieser Mehrdeutigkeit trägt der Kunde; der Anbieter kann nur ehrlich veröffentlichen, was er ehrlich veröffentlichen kann.

Behandeln Sie Canaries als eines von mehreren Signalen für kulturelle Integrität, nicht als Sicherheitsgarantie. Ein Canary sagt Ihnen, dass ein Anbieter Zwang für ein reales genug Risiko hält, um Entwicklungsaufwand in das Vorab-Veröffentlichen des Widerspruchssignals zu investieren. Das ist bedeutsam. Es ist nicht dasselbe wie ein kryptografischer Beweis.

FAQ

Warrant Canary — häufige Fragen

Was ist ein Warrant Canary?

A warrant canary is a regularly-published statement that a service provider has not yet received certain types of legal process — most commonly a National Security Letter, a gag order, or a bulk surveillance demand. The canary is published in the affirmative ("we have not received…") on a fixed cadence (weekly, monthly, quarterly). The legal logic is asymmetric: a gag order can compel silence about a received order, but most jurisdictions cannot compel a person to make an affirmative false statement. So the warrant canary continues until it stops — and the absence of the next scheduled canary is the signal that something has changed.

How does a warrant canary actually work in law?

The mechanism depends on a specific gap in compelled-speech doctrine. Many surveillance statutes — 18 USC §2709 for US National Security Letters, similar provisions in other 14-Eyes jurisdictions — include non-disclosure clauses preventing the recipient from talking about the order. Those clauses compel silence. They do not, in most cases, compel the recipient to actively lie. So if a provider has been publishing "we have not received an NSL" weekly for two years, and one week the statement does not appear (or its language changes), that absence is itself information that the gag-order regime cannot suppress. The legal theory has not been definitively tested in court for every statute in every jurisdiction — see "Limitations" below for the honest caveats.

Is a warrant canary legally binding?

Not in the contractual sense. A canary is a unilateral, public attestation by the provider, not a covenant with any specific customer. What makes it useful is that (a) it is signed with the provider's PGP key, so anyone can verify it came from the same key that signed every prior canary; (b) it is timestamped, so the absence of a renewal is detectable; and (c) the provider's reputation and their threat model are aligned around its continued publication. A canary is more like a firmware-version attestation than a contract — useful evidence in the absence of a deception, useless once you suspect a deception.

How do I verify a PGP-signed warrant canary?

Four steps. (1) Download the provider's public PGP key from their website (BitVPS publishes ours at /pgp/ — verify the fingerprint matches the one published on the warrant-canary page itself). (2) Import the key with `gpg --import bitvps-pubkey.asc`. (3) Download the signed canary text. (4) Run `gpg --verify canary.asc` to check the signature. Successful verification proves: the canary was signed by the holder of the published key, AND the canary text has not been modified since signing. If verification fails, treat the canary as untrusted. Cross-check the fingerprint against multiple sources (the provider's site, archive.org snapshots, third-party PGP keyservers) to defend against a key-substitution attack.

What does it mean when a canary "dies"?

Canary death — the absence of an expected scheduled renewal — is most often administrative oversight, not the receipt of an NSL. Real-world history: most canary-renewal failures in the last decade have been because the engineer responsible was on vacation, the cron job hit a credential-rotation, or the company forgot. The signal is genuinely ambiguous. If a canary fails to renew, the right interpretation is "investigate further" rather than "the provider has been served". Cross-reference: ask other customers, check archive.org, look for community discussion on the relevant subreddits or hacker forums. A single missed canary is weak signal; a missed canary plus organisational silence plus a key change plus removal of the canary URL is strong signal.

Why don't bigger providers publish canaries?

Several reasons, none of them flattering. First, large publicly-traded providers face shareholder-litigation risk if a canary is interpreted as material non-public information — much easier to publish nothing than to publish a statement that might trigger a 10-Q disclosure debate. Second, the legal theory underlying canaries is unsettled: a provider's general counsel can plausibly argue that publishing one creates litigation exposure. Third, large providers receive enough surveillance demands that publishing a "we have not received" canary would be perjury immediately — at scale, the canary is incompatible with the operating reality. Smaller privacy-focused providers can credibly publish canaries because they receive few or no qualifying orders; very large providers cannot.

Are canaries useful, or are they security theatre?

Honest answer: they are useful as one signal among several, not as a security guarantee. A canary tells you that a provider thinks adversarial coercion is a real enough risk to invest engineering effort in pre-publishing the contradiction signal. That is meaningful cultural information about who you are dealing with. The canary itself is not cryptographic proof of non-coercion — it is cultural proof of coercion-aware operations. Combine canary publication with other signals (jurisdiction, ownership transparency, transparency reports, abuse-handling track record, PGP key continuity) for a meaningful overall picture. A canary alone is not enough; a canary plus everything else above is meaningful.

Where can I find a list of providers with active canaries?

The canonical reference is the Canary Watch project (originally maintained by EFF, now defunct as a centralised list since 2016) and the Wikipedia "Warrant canary" article, which maintains a partial list. We list the providers we know maintain active canaries in the table on this page — we have deliberately kept it short and verifiable rather than long and aspirational. The list shifts: Apple removed theirs in 2014, Reddit in 2016, Tumblr at various points. We update this page when we change the list. If you maintain a public canary and are not on this page, send us the URL through /panel/?section=support and we will verify and add you.

Quellen

Quellen, auf die wir uns stützten

Den Live-Canary ansehen — wöchentlich überprüft.

BitVPS signiert den Canary jeden Montag neu. Die aktuelle Erklärung, das Archiv jeder vorherigen Woche und der PGP-Schlüssel zur Verifizierung befinden sich alle auf /canary/.

Den Live-BitVPS-Canary ansehen Den PGP-Schlüssel herunterladen