A warrant canary is a regularly-published, PGP-signed statement that a service provider has not received certain types of legal process — most commonly a National Security Letter, a gag order, or a bulk surveillance demand. The canary continues until it stops. The absence of the next scheduled canary is the signal that something changed. This page explains the mechanism, walks through PGP verification, and lists the providers who maintain one in 2026.
بهروزرسانیشده · نویسنده: مهندسی Cryptoservers
The warrant canary depends on a specific asymmetry in compelled-speech doctrine. Many surveillance statutes — 18 USC §2709 in the United States (the National Security Letter authority); analogous provisions in the UK Investigatory Powers Act 2016 (§133 non-disclosure); equivalents in other 14-Eyes jurisdictions — include non-disclosure clauses that prevent the recipient of an order from talking about it. Those clauses compel silence. They do not, in most jurisdictions, compel the recipient to actively make a false affirmative statement.
That distinction is what the canary exploits. A provider publishes "we have not received an NSL as of [date]" on a fixed cadence — weekly, monthly, quarterly. As long as the statement remains true, publication continues. If the provider receives an order, they cannot say so directly (gag order). But they can stop publishing the affirmative statement. The next scheduled canary either does not appear, or appears with the relevant clause removed, or appears with different language. That absence — that change — is information that the gag order cannot suppress.
The Cryptoservers canary, published at /canary/, follows this pattern. Every Monday we re-sign a statement covering the week ending the prior Sunday. The signed statement enumerates: NSLs received (target: zero), gag orders received (target: zero), bulk-retention orders received (target: zero), per-jurisdiction order counts (Saint Kitts and Nevis, Iceland, Netherlands, Romania, Switzerland), DMCA notices received versus actioned, and abuse complaints received versus actioned. Five of the six numbers are expected to be zero in a normal week; the abuse and DMCA numbers are non-zero by design (we receive abuse complaints, and we publish how many).
The cadence matters. A canary published once a year carries less signal than one published weekly — the lag between coercion and the customer noticing is the freshness window. Weekly canaries reduce that window to seven days; daily canaries (rare, because they require key-handling at scale) reduce it to twenty-four hours. Quarterly canaries leave a three-month window in which a provider could be compromised before any external observer notices.
A canary that is not cryptographically signed is theatre. Verification takes four steps and about ninety seconds. The example below uses the Cryptoservers canary; the same procedure works for any provider that publishes a PGP-signed canary.
گام ۱ — کلید عمومی را از ارائهدهنده دریافت کنید. Cryptoservers کلید عمومی PGP را در این آدرس منتشر میکند: /pgp/. The key fingerprint is documented on multiple pages of the website (about, canary, pgp, footer) so a single-page tampering attempt is detectable. Cross-reference the fingerprint against multiple sources — archive.org snapshots, the Wayback Machine, third-party PGP keyservers — before you trust it.
curl -O https://cryptoservers.io/pgp/cryptoservers-pubkey.asc
gpg --show-keys cryptoservers-pubkey.asc
گام ۲ — کلید را وارد کنید. در کلیدخانهی محلی GnuPG خود وارد کنید. کلید در فروشگاه محلی شما میماند — نیازی به بارگذاری نیست، به اعتماد شخص ثالث نیازی نیست.
gpg --import cryptoservers-pubkey.asc
گام ۳ — متن canary امضاشده را دانلود کنید. The canary at /canary/ is rendered HTML, but the underlying signed file is also available as a clearsigned .asc — visible at the bottom of the canary page or directly via the storage path. For the purposes of this example, save it as canary.asc in your working directory.
curl -O https://cryptoservers.io/canary/latest.asc
گام ۴ — امضا را تأیید کنید. دستور gpg --verify را روی فایل .asc اجرا کنید. یک خط «Good signature» دو چیز را تأیید میکند: canary توسط دارندهی کلید وارد شده امضا شده، و متن canary پس از امضا تغییر نکرده است. تأیید ناموفق به معنای تغییر فایل، نامعتبر بودن امضا یا عدم تطابق کلید است — canary را غیرقابل اعتماد تلقی کنید و بیشتر تحقیق کنید.
gpg --verify canary.asc
# expected:
# gpg: Good signature from "Cryptoservers Ltd. <[email protected]>"
# gpg: Primary key fingerprint: 4DCF 5D6D 10AF F2AA 47E2 070E A62A EDAF 647E E3E6
اگر قبلاً از GnuPG استفاده نکردهاید، ابتدا آن را نصب کنید: `apt install gnupg2` در لینوکس خانوادهی Debian، `brew install gnupg` در macOS، یا GPG4Win را در ویندوز دانلود کنید. مرحلهی تأیید خود در همهی پلتفرمها یکسان است.
فهرست کوتاه، قابل تأیید. مثالهای تاریخی (Apple 2013–2014، Reddit 2014–2016) را برای زمینه گنجاندهایم — آنها بهعنوان مطالعات موردی نحوهی سیگنالدهی canary به تغییر مفیدند. اگر canary عمومی دارید که اینجا فهرست نشده، از طریق /contact/ به ما بفرستید.
| ارائهدهنده / پروژه | تناوب | اولین انتشار | وضعیت | یادداشتها |
|---|---|---|---|---|
| rsync.net | Quarterly, PGP-signed | 2014 | Maintained | One of the earliest commercial canaries. Includes Bitcoin block-hash as a freshness anchor. |
| Cryptoservers | 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. |
این فهرست را عمداً کوتاه نگه میداریم. یک فهرست بلندپروازانهی طولانی سیگنال را رقیق میکند — ارزش canary در قابل تأیید بودن آن است، و تأیید در مقیاس بزرگ پرهزینه است. وقتی تغییر میدهیم فهرست را بهروز میکنیم؛ فیلد dateModified این صفحه آخرین پاس تأیید را نشان میدهد.
پاسخ صادقانه: کمتر از آنچه متن بازاریابی نشان میدهد. دلیل غالب از دست رفتن canary در دههی گذشته دریافت National Security Letter نبوده، بلکه اشتباه اداری بوده است. مهندس مسئول در تعطیلات بود، cronjob به چرخش اعتبارنامه برخورد کرد، DNS زیردامنهی canary منقضی شد، شرکت فراموش کرد. یک تمدید از دست رفته ضعیف در بهترین حالت یک سیگنال.
چیزی که سیگنال ضعیف را به سیگنال قوی تبدیل میکند، تأیید متقابل است. به دنبال این موارد بگردید:
Apple's 2014 canary removal is the canonical case study. The September 2013 transparency report contained the line "Apple has never received an order under Section 215 of the USA Patriot Act." The September 2014 transparency report did not. Apple issued no public statement explaining the change. Privacy researchers (Christopher Soghoian, then with the ACLU; Glenn Greenwald at The Intercept) flagged the absence within days. The signal was weak at first — could have been an editorial change — but the absence persisted across subsequent reports, and Apple's general counsel did not subsequently re-affirm the canary statement when directly asked. Two years later the consensus interpretation in the privacy-research community was that Apple had received a Section 215 order. Apple has never confirmed or denied this.
The right interpretation of a missed canary is "investigate further", not "the provider has been served". Canaries are evidence in the absence of deception, not proof in its presence.
Three honest limits that you should weigh before treating a canary as cryptographic proof of provider integrity.
۱. نظریه حقوقی به منفذهای قانونی وابسته است. The canary exploits a doctrine that gag orders compel silence rather than affirmative falsehood. That doctrine has not been definitively tested for every surveillance statute in every jurisdiction. The Stanford Law Review and other legal scholars have argued both sides. A determined prosecutor could plausibly argue that compelling continued affirmative publication of "we have not received" is itself part of a non-disclosure obligation, and that ceasing publication is a breach of the gag. The legal theory has held up so far in published US case law, but it has not been litigated to definitive resolution. Other jurisdictions are even less tested.
۲. canary های امضانشده بیفایدهاند. A canary that is not signed with a verifiable PGP key — or that uses a key whose fingerprint cannot be cross-referenced against multiple independent sources — is theatre. An adversary who controls the provider's website can substitute a forged "everything is fine" canary and there is no way to detect the substitution. The PGP signature is what makes the canary load-bearing. Unsigned text is not a canary, no matter what it says. Verify before you trust.
۳. canary های منقضی مبهم هستند. When a canary stops being renewed, the interpretation depends on what else is happening. A lapsed canary plus organisational silence plus a key change is strong signal. A lapsed canary alone is weak — it could mean the engineer is on vacation. A canary that never started is no signal at all. The burden of disambiguation falls on the customer; the provider can only honestly publish what they can honestly publish.
Treat canaries as one cultural-integrity signal among several, not as a security guarantee. A canary tells you that a provider thinks coercion is a real enough risk to invest engineering effort in pre-publishing the contradiction signal. That is meaningful. It is not the same thing as cryptographic proof.
Cryptoservers هر دوشنبه warrant canary را دوباره امضا میکند. بیانیهی جاری، آرشیو هر هفتهی پیشین و کلید PGP برای تأیید همگی در /canary/ موجودند.