یک warrant canary چیست، و چرا اهمیت دارد؟

کاناری حکم قضایی بیانیه‌ای است که مرتب منتشر و با PGP امضا می‌شود و نشان می‌دهد یک ارائه‌دهندهٔ سرویس انواع خاصی از روند قانونی را دریافت نکرده است — رایج‌ترین آن‌ها نامهٔ امنیت ملی، حکم منع افشا یا درخواست نظارت انبوه. کاناری ادامه می‌یابد تا زمانی که متوقف شود. نبودِ کاناری برنامه‌ریزی‌شدهٔ بعدی، نشانهٔ این است که چیزی تغییر کرده است. این صفحه سازوکار را توضیح می‌دهد، تأیید PGP را گام‌به‌گام طی می‌کند و ارائه‌دهندگانی را که در سال ۲۰۲۶ کاناری نگه می‌دارند فهرست می‌کند.

به‌روزرسانی‌شده 2026-05-03 · نویسنده: مهندسی BitVPS

مشاهده canary زنده BitVPS ← چگونه یک canary را تأیید کنیم

سازوکار

یک warrant canary چگونه کار می‌کند — منطق حقوقی

کاناری حکم قضایی به یک عدم‌تقارن خاص در دکترین گفتار اجباری متکی است. بسیاری از قوانین نظارتی — 18 USC §2709 در ایالات متحده (اختیار نامهٔ امنیت ملی)؛ مفاد مشابه در قانون اختیارات تحقیقاتی بریتانیا ۲۰۱۶ (§133 منع افشا)؛ معادل‌هایی در دیگر حوزه‌های قضایی ۱۴-Eyes — شامل بندهای منع افشا هستند که گیرندهٔ یک حکم را از سخن‌گفتن دربارهٔ آن باز می‌دارند. این بندها سکوت را تحمیل می‌کنند. آن‌ها، در بیشتر حوزه‌های قضایی، گیرنده را وادار نمی‌کنند که فعالانه یک اظهار اثباتی نادرست بیان کند.

همین تمایز است که کاناری از آن بهره می‌برد. یک ارائه‌دهنده عبارت «تا تاریخ [date] هیچ NSL دریافت نکرده‌ایم» را با آهنگی ثابت منتشر می‌کند — هفتگی، ماهانه، فصلی. تا زمانی که این بیانیه درست بماند، انتشار ادامه می‌یابد. اگر ارائه‌دهنده حکمی دریافت کند، نمی‌تواند مستقیماً آن را بگوید (حکم منع افشا). اما می‌تواند انتشار بیانیهٔ اثباتی را متوقف کند. کاناری برنامه‌ریزی‌شدهٔ بعدی یا ظاهر نمی‌شود، یا با حذف بند مربوطه ظاهر می‌شود، یا با عبارتی متفاوت ظاهر می‌شود. آن نبود — آن تغییر — اطلاعاتی است که حکم منع افشا نمی‌تواند آن را سرکوب کند.

کاناری BitVPS که در /canary/ منتشر می‌شود از همین الگو پیروی می‌کند. هر دوشنبه بیانیه‌ای را که هفتهٔ منتهی به یکشنبهٔ پیشین را پوشش می‌دهد دوباره امضا می‌کنیم. بیانیهٔ امضاشده این موارد را برمی‌شمارد: NSLهای دریافتی (هدف: صفر)، احکام منع افشای دریافتی (هدف: صفر)، احکام نگهداری انبوه دریافتی (هدف: صفر)، شمار احکام به‌تفکیک حوزهٔ قضایی (سنت کیتس و نویس، ایسلند، هلند، رومانی، سوئیس)، اخطارهای DMCA دریافت‌شده در برابر اقدام‌شده، و شکایت‌های سوءاستفاده دریافت‌شده در برابر اقدام‌شده. انتظار می‌رود پنج عدد از این شش عدد در یک هفتهٔ عادی صفر باشند؛ اعداد سوءاستفاده و DMCA به‌صورت طراحی‌شده غیرصفرند (ما شکایت‌های سوءاستفاده دریافت می‌کنیم و تعداد آن‌ها را منتشر می‌کنیم).

آهنگ انتشار اهمیت دارد. کاناری‌ای که سالی یک‌بار منتشر می‌شود نشانهٔ کمتری نسبت به کاناری هفتگی دارد — فاصلهٔ میان اجبار و متوجه‌شدن مشتری همان پنجرهٔ تازگی است. کاناری‌های هفتگی این پنجره را به هفت روز کاهش می‌دهند؛ کاناری‌های روزانه (که نادرند، چون به مدیریت کلید در مقیاس بالا نیاز دارند) آن را به بیست‌وچهار ساعت می‌رسانند. کاناری‌های فصلی یک پنجرهٔ سه‌ماهه باقی می‌گذارند که در آن یک ارائه‌دهنده می‌تواند پیش از آنکه هر ناظر بیرونی متوجه شود، به خطر بیفتد.

تأیید PGP

تأیید یک canary امضاشده با PGP — چهار گام

کاناری‌ای که از نظر رمزنگاری امضا نشده باشد، نمایشی توخالی است. تأیید چهار گام و حدود نود ثانیه طول می‌کشد. مثال زیر از کاناری BitVPS استفاده می‌کند؛ همین روند برای هر ارائه‌دهنده‌ای که یک کاناری امضاشده با PGP منتشر می‌کند کار می‌کند.

گام ۱ — کلید عمومی را از ارائه‌دهنده دریافت کنید. BitVPS کلید عمومی PGP را در این آدرس منتشر می‌کند: /pgp/. اثرانگشت کلید در چند صفحهٔ وب‌سایت مستند شده است (about، canary، pgp، فوتر) تا تلاش برای دستکاری یک صفحهٔ تنها قابل‌تشخیص باشد. پیش از آنکه به آن اعتماد کنید، اثرانگشت را با چند منبع مقابله کنید — تصویرهای آرشیوی archive.org، Wayback Machine، سرورهای کلید PGP شخص ثالث.

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

گام ۲ — کلید را وارد کنید. در کلیدخانه‌ی محلی GnuPG خود وارد کنید. کلید در فروشگاه محلی شما می‌ماند — نیازی به بارگذاری نیست، به اعتماد شخص ثالث نیازی نیست.

gpg --import bitvps-pubkey.asc

گام ۳ — متن canary امضاشده را دانلود کنید. کاناری در /canary/ به‌صورت HTML رندر می‌شود، اما فایل امضاشدهٔ زیربنایی نیز به‌صورت یک ‎.asc با امضای متن‌باز در دسترس است — در پایین صفحهٔ کاناری یا مستقیماً از طریق مسیر ذخیره‌سازی قابل‌مشاهده است. برای این مثال، آن را با نام canary.asc در پوشهٔ کاری خود ذخیره کنید.

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

گام ۴ — امضا را تأیید کنید. دستور gpg --verify را روی فایل .asc اجرا کنید. یک خط «Good signature» دو چیز را تأیید می‌کند: canary توسط دارنده‌ی کلید وارد شده امضا شده، و متن canary پس از امضا تغییر نکرده است. تأیید ناموفق به معنای تغییر فایل، نامعتبر بودن امضا یا عدم تطابق کلید است — canary را غیرقابل اعتماد تلقی کنید و بیشتر تحقیق کنید.

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

اگر قبلاً از GnuPG استفاده نکرده‌اید، ابتدا آن را نصب کنید: `apt install gnupg2` در لینوکس خانواده‌ی Debian، `brew install gnupg` در macOS، یا GPG4Win را در ویندوز دانلود کنید. مرحله‌ی تأیید خود در همه‌ی پلتفرم‌ها یکسان است.

canary های فعال

هاست‌ها و سازمان‌ها که یک warrant canary نگهداری می‌کنند

فهرست کوتاه، قابل تأیید. مثال‌های تاریخی (Apple 2013–2014، Reddit 2014–2016) را برای زمینه گنجانده‌ایم — آنها به‌عنوان مطالعات موردی نحوه‌ی سیگنال‌دهی canary به تغییر مفیدند. اگر canary عمومی دارید که اینجا فهرست نشده، از طریق /panel/?section=support به ما بفرستید.

ارائه‌دهنده / پروژه	تناوب	اولین انتشار	وضعیت	یادداشت‌ها
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.

این فهرست را عمداً کوتاه نگه می‌داریم. یک فهرست بلندپروازانه‌ی طولانی سیگنال را رقیق می‌کند — ارزش canary در قابل تأیید بودن آن است، و تأیید در مقیاس بزرگ پرهزینه است. وقتی تغییر می‌دهیم فهرست را به‌روز می‌کنیم؛ فیلد dateModified این صفحه آخرین پاس تأیید را نشان می‌دهد.

بخش صادقانه

یک canary گم‌شده چه معنایی دارد واقعاً چه معنایی دارد؟

پاسخ صادقانه: کمتر از آنچه متن بازاریابی نشان می‌دهد. دلیل غالب از دست رفتن canary در دهه‌ی گذشته دریافت National Security Letter نبوده، بلکه اشتباه اداری بوده است. مهندس مسئول در تعطیلات بود، cronjob به چرخش اعتبارنامه برخورد کرد، DNS زیردامنه‌ی canary منقضی شد، شرکت فراموش کرد. یک تمدید از دست رفته ضعیف در بهترین حالت یک سیگنال.

چیزی که سیگنال ضعیف را به سیگنال قوی تبدیل می‌کند، تأیید متقابل است. به دنبال این موارد بگردید:

canary که به‌روزرسانی برنامه‌ریزی‌شده‌اش را از دست بدهد و سپس با زبان تغییریافته به شکل اساسی ظاهر می‌شود (بند حذف شده، تعداد حوزه قضایی تغییر کرده، دامنه محدود شده).
شکست canary که با گزارش عمومی یک موضوع حقوقی مربوط به ارائه‌دهنده همزمان است.
تغییر کلید PGP همراه با اختلال canary — به‌ویژه اگر کلید جدید بدون اعتبارسنجی چندمنبعه‌ی اثر انگشتی که کلید اصلی داشت منتشر شده باشد.
سکوت سازمانی — هیچ بیانیه‌ی عمومی توضیح‌دهنده‌ی اختلال، هیچ تأیید در شبکه‌های اجتماعی، هیچ پاسخ به پرسش‌های مستقیم مشتریان.
ناگهانی در دسترس نبودن خود URL canary، به‌خصوص اگر نسخه‌های کَش‌شده در archive.org نیز حذف شده باشند.

حذف کاناری اپل در سال ۲۰۱۴ مطالعهٔ موردی شاخص است. گزارش شفافیت سپتامبر ۲۰۱۳ شامل این خط بود: «اپل هرگز حکمی تحت بخش ۲۱۵ قانون میهن‌پرستی ایالات متحده دریافت نکرده است.» گزارش شفافیت سپتامبر ۲۰۱۴ آن را نداشت. اپل هیچ بیانیهٔ عمومی‌ای برای توضیح این تغییر صادر نکرد. پژوهشگران حریم خصوصی (کریستوفر سوغویان، آن زمان در ACLU؛ گلن گرینوالد در The Intercept) ظرف چند روز این نبود را برجسته کردند. نشانه در ابتدا ضعیف بود — می‌توانست یک تغییر ویرایشی باشد — اما این نبود در گزارش‌های بعدی پایدار ماند، و مشاور حقوقی اپل هنگامی که مستقیماً از او پرسیده شد، بیانیهٔ کاناری را دوباره تأیید نکرد. دو سال بعد، تفسیر اجماعی در جامعهٔ پژوهش حریم خصوصی این بود که اپل یک حکم بخش ۲۱۵ دریافت کرده است. اپل هرگز این را تأیید یا تکذیب نکرده است.

تفسیر درست یک کاناری ازدست‌رفته «تحقیق بیشتر» است، نه «به ارائه‌دهنده ابلاغ شده است». کاناری‌ها در نبود فریب، شاهدند، نه در حضور آن، دلیل.

محدودیت‌ها

محدودیت‌های canary ها به‌عنوان یک سیگنال

سه محدودیت صادقانه که باید پیش از آنکه یک کاناری را اثبات رمزنگاری‌شدهٔ یکپارچگی ارائه‌دهنده بدانید، آن‌ها را بسنجید.

۱. نظریه حقوقی به منفذهای قانونی وابسته است. کاناری از دکترینی بهره می‌برد که احکام منع افشا سکوت را تحمیل می‌کنند نه دروغ اثباتی را. این دکترین برای هر قانون نظارتی در هر حوزهٔ قضایی به‌طور قطعی آزموده نشده است. Stanford Law Review و دیگر پژوهشگران حقوقی هر دو طرف را استدلال کرده‌اند. یک دادستان مصمم می‌تواند به‌طور محتمل استدلال کند که اجبار به انتشار اثباتی مستمر عبارت «دریافت نکرده‌ایم» خود بخشی از یک تعهد منع افشاست، و توقف انتشار نقض حکم منع افشاست. این نظریهٔ حقوقی تاکنون در رویهٔ قضایی منتشرشدهٔ ایالات متحده پابرجا مانده است، اما تا حل‌وفصل قطعی به دادگاه کشیده نشده است. دیگر حوزه‌های قضایی حتی کمتر آزموده شده‌اند.

۲. canary های امضانشده بی‌فایده‌اند. کاناری‌ای که با یک کلید PGP قابل‌تأیید امضا نشده باشد — یا که از کلیدی استفاده کند که اثرانگشت آن را نمی‌توان با چند منبع مستقل مقابله کرد — نمایشی توخالی است. یک متخاصم که کنترل وب‌سایت ارائه‌دهنده را در دست دارد می‌تواند یک کاناری جعلی «همه‌چیز خوب است» را جایگزین کند و هیچ راهی برای تشخیص این جایگزینی وجود ندارد. امضای PGP همان چیزی است که کاناری را اتکاپذیر می‌کند. متن بدون امضا یک کاناری نیست، فارغ از اینکه چه می‌گوید. پیش از اعتماد، تأیید کنید.

۳. canary های منقضی مبهم هستند. وقتی یک کاناری دیگر تمدید نمی‌شود، تفسیر آن به این بستگی دارد که چه چیز دیگری در حال رخ‌دادن است. یک کاناری منقضی‌شده به‌علاوهٔ سکوت سازمانی به‌علاوهٔ یک تغییر کلید، نشانهٔ قوی است. یک کاناری منقضی‌شده به‌تنهایی ضعیف است — می‌تواند به این معنا باشد که مهندس در تعطیلات است. کاناری‌ای که هرگز آغاز نشده، اصلاً نشانه‌ای نیست. بار رفع ابهام بر دوش مشتری است؛ ارائه‌دهنده تنها می‌تواند صادقانه آنچه را که می‌تواند صادقانه منتشر کند، منتشر کند.

کاناری‌ها را یکی از چند نشانهٔ یکپارچگی فرهنگی بدانید، نه یک تضمین امنیتی. یک کاناری به شما می‌گوید که ارائه‌دهنده اجبار را خطری به‌اندازهٔ کافی واقعی می‌داند که برای پیش‌انتشار نشانهٔ تناقض، تلاش مهندسی صرف کند. این معنادار است. اما با اثبات رمزنگاری‌شده یکی نیست.

سؤالات متداول

warrant canary — پرسش‌های پربسامد

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.

استنادها

منابعی که به آن‌ها متکی بودیم

مشاهده canary زنده — به‌صورت هفتگی تأیید می‌شود.

BitVPS هر دوشنبه warrant canary را دوباره امضا می‌کند. بیانیه‌ی جاری، آرشیو هر هفته‌ی پیشین و کلید PGP برای تأیید همگی در /canary/ موجودند.

مشاهده canary زنده BitVPS دانلود کلید PGP