什么是 warrant canary，为何重要？

授权令金丝雀声明（warrant canary）是一份定期发布、经 PGP 签名的声明，表明某服务提供商尚未收到某些类型的法律程序——最常见的是国家安全函（NSL）、封口令，或大规模监控要求。金丝雀声明会一直延续，直到它停止。下一次按计划应发布的金丝雀声明缺席，就是某事已经改变的信号。本页解释这一机制，逐步演示 PGP 验证，并列出 2026 年维护此声明的提供商。

更新时间 2026-05-03 · 作者： BitVPS 工程团队

查看 BitVPS 实时 warrant canary → 如何验证 warrant canary

机制

Warrant canary 的工作原理—— 法律逻辑

授权令金丝雀声明依赖于强制言论原则中的一种特定不对称性。许多监控法规——美国的 18 USC §2709（国家安全函授权）；英国《2016 年调查权法》中的类似条款（§133 禁止披露）；以及其他 14 眼司法辖区的对应规定——都包含禁止披露条款，阻止命令的接收方谈论该命令。这些条款强制其保持沉默。 在大多数司法辖区，这些条款并不强制接收方主动做出虚假的肯定陈述。

正是这一区别被金丝雀声明所利用。提供商以固定节奏——每周、每月、每季度——发布"截至 [日期] 我们尚未收到 NSL"。只要该陈述仍然属实，发布就会继续。如果提供商收到了命令，他们不能直接说出来（封口令）。但他们可以停止发布这条肯定陈述。下一次按计划应发布的金丝雀声明要么不再出现，要么去掉相关条款后出现，要么以不同措辞出现。那种缺席——那种变化——正是封口令无法压制的信息。

BitVPS 的金丝雀声明发布于 /canary/，遵循这一模式。每周一我们都会重新签署一份涵盖至上一个周日为止那一周的声明。这份签名声明逐项列出：收到的 NSL 数（目标：零）、收到的封口令数（目标：零）、收到的大规模留存命令数（目标：零）、各司法辖区的命令数（圣基茨和尼维斯、冰岛、荷兰、罗马尼亚、瑞士）、收到的 DMCA 通知数与已处理数，以及收到的滥用投诉数与已处理数。六个数字中有五个在正常的一周里预期为零；滥用和 DMCA 数字按设计为非零（我们会收到滥用投诉，并公布数量）。

节奏很重要。一年发布一次的金丝雀声明，其信号弱于每周发布一次的——从被胁迫到客户察觉之间的时滞，就是新鲜度窗口。每周的金丝雀声明把这一窗口缩短至七天；每日的金丝雀声明（罕见，因为需要大规模的密钥处理）把它缩短至二十四小时。每季度的金丝雀声明则留出三个月的窗口，在此期间提供商可能在任何外部观察者察觉之前已被攻陷。

PGP 验证

验证 PGP 签名的 warrant canary—— 四个步骤

一份未经密码学签名的金丝雀声明只是作秀。验证只需四步、约九十秒。下面的示例使用 BitVPS 的金丝雀声明；同样的流程适用于任何发布经 PGP 签名金丝雀声明的提供商。

第 1 步——从提供商处获取公钥。 BitVPS 在以下地址发布 PGP 公钥 /pgp/。该密钥的指纹记录在网站的多个页面上（关于、金丝雀、pgp、页脚），因此单页篡改是可被发现的。在你信任它之前，请将指纹与多个来源交叉核对——archive.org 的快照、Wayback Machine、第三方 PGP 密钥服务器。

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

第 2 步——导入密钥。 导入到你本地的 GnuPG 密钥环中。密钥保留在你的本地存储里——无需上传，无需第三方信任。

gpg --import bitvps-pubkey.asc

第 3 步——下载已签名的金丝雀声明文本。 /canary/ 处的金丝雀声明是渲染后的 HTML，但其底层的已签名文件也以明文签名的 .asc 形式提供——可在金丝雀声明页面底部看到，或直接通过存储路径访问。就本示例而言，请将其保存为工作目录中的 canary.asc。

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

第 4 步——验证签名。 对 .asc 文件运行 gpg --verify。出现"Good signature"一行可确认两件事：金丝雀声明由所导入密钥的持有者签署，并且金丝雀声明文本自签署以来未被改动。验证失败则意味着文件已被修改、签名无效，或密钥不匹配——请将该金丝雀声明视为不可信，并进一步调查。

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，请先安装它：Debian 系 Linux 上 `apt install gnupg2`，macOS 上 `brew install gnupg`，Windows 上下载 GPG4Win。验证步骤本身在每个平台上都相同。

活跃的 warrant canary

主机商与组织维护 warrant canary 的

简短清单，可验证。我们纳入了历史案例（Apple 2013–2014、Reddit 2014–2016）作为背景——作为 warrant canary 如何发出变化信号的案例研究很有价值。如果您维护的公开 warrant 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.

我们刻意把这份名单保持得很短。一份冗长而理想化的名单会稀释信号——金丝雀声明的价值在于它可被验证，而大规模验证代价高昂。我们更改名单时会更新它；本页上的 dateModified 字段反映了最近一次验证的时间。

诚实说明

缺失的 warrant canary 实际意味着什么？

坦诚的答案：比营销文案暗示的要少。过去十年里，金丝雀声明缺席的主要原因并不是收到了国家安全函——而是行政疏忽。负责的工程师在休假、定时任务撞上了凭据轮换、金丝雀子域名的 DNS 过期了、公司忘了。单次错过续发是弱充其量是一个信号。

把弱信号变成强信号的，是佐证。请留意：

错过预定续签的 warrant canary 与随后以实质性修改的语言出现（条款删除、司法管辖区数量变更、范围缩窄）。
与涉及该供应商的法律事项公开报道同时发生的 warrant canary 失效。
伴随 warrant canary 中断的 PGP 密钥更换——特别是新密钥未经原密钥所具有的多来源指纹交叉验证即发布。
组织沉默——无公开声明解释中断原因，无社交媒体确认，无对客户直接查询的回应。
Warrant canary URL 本身突然不可访问，尤其是 archive.org 上的缓存版本也被删除。

Apple 在 2014 年移除金丝雀声明是经典案例研究。2013 年 9 月的透明度报告包含这样一行："Apple 从未收到过依据《美国爱国者法》第 215 条的命令。"2014 年 9 月的透明度报告则没有。Apple 未就这一变化发表任何公开声明。隐私研究人员（当时在 ACLU 的 Christopher Soghoian；The Intercept 的 Glenn Greenwald）在几天内便指出了这一缺席。信号起初很弱——可能只是编辑上的改动——但这一缺席在后续报告中持续存在，且当被直接问及时，Apple 的总法律顾问此后并未重新确认那条金丝雀陈述。两年后，隐私研究界的共识解读是 Apple 已收到一份第 215 条命令。Apple 从未对此予以证实或否认。

对金丝雀声明缺席的正确解读是"进一步调查"，而非"该提供商已被送达命令"。在没有欺骗的前提下，金丝雀声明是证据；在存在欺骗的情况下，它并非证明。

局限

Warrant canary 的局限性作为信号

在把金丝雀声明当作提供商诚信的密码学证明之前，你应当权衡的三条坦诚的局限。

1. 这套法律理论依赖于漏洞。 金丝雀声明利用的是这样一条原则：封口令强制的是沉默，而非肯定的虚假陈述。该原则并未针对每个司法辖区的每一部监控法规都得到确定性的检验。《斯坦福法律评论》及其他法律学者对正反两方均有论述。一位决心十足的检察官完全可能辩称：强制持续肯定地发布"我们尚未收到"本身就是禁止披露义务的一部分，而停止发布即构成对封口令的违反。这套法律理论在已公布的美国判例法中迄今站得住脚，但尚未经过诉讼达到确定性的定论。其他司法辖区的检验则更少。

2. 未签名的金丝雀声明毫无用处。 一份未用可验证的 PGP 密钥签名的金丝雀声明——或所用密钥的指纹无法与多个独立来源交叉核对——只是作秀。控制了提供商网站的对手可以替换成一份伪造的"一切正常"金丝雀声明，而你无从察觉这一替换。PGP 签名才是使金丝雀声明具有承载力的关键。未签名的文本无论说什么，都不是金丝雀声明。请在信任之前先验证。

3. 失效的金丝雀声明含义模糊。 当一份金丝雀声明停止续发时，其解读取决于还发生了什么。一份失效的金丝雀声明加上组织的沉默再加上密钥变更，是强信号。单单一份失效的金丝雀声明则是弱信号——它可能意味着工程师在休假。一份从未开始过的金丝雀声明则根本不构成信号。消除歧义的负担落在客户身上；提供商只能诚实地发布他们能够诚实发布的内容。

将 warrant 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.

引用来源

我们依赖的资料来源

查看实时 warrant canary—— 每周验证。

BitVPS 每周一重新签署金丝雀声明。当前的声明、此前每一周的存档，以及用于验证的 PGP 密钥，全都在 /canary/。

查看 BitVPS 实时 warrant canary 下载 PGP 密钥

什么是 warrant canary， 为何重要？