O que é um warrant canary, e por que importa?

Um warrant canary é uma declaração publicada regularmente e assinada com PGP atestando que um provedor de serviços não recebeu determinados tipos de processo legal — mais comumente uma National Security Letter, uma ordem de mordaça (gag order) ou uma demanda de vigilância em massa. O canary continua até parar. A ausência do próximo canary previsto é o sinal de que algo mudou. Esta página explica o mecanismo, percorre a verificação PGP e lista os provedores que mantêm um em 2026.

Atualizado 2026-05-03 · Autor: Engenharia BitVPS

Veja o canary ao vivo da BitVPS → Como verificar um canário

Mecanismo

Como funciona um warrant canary — a lógica jurídica

O warrant canary depende de uma assimetria específica na doutrina da expressão compelida. Muitos estatutos de vigilância — 18 USC §2709 nos Estados Unidos (a autoridade das National Security Letters); disposições análogas no UK Investigatory Powers Act 2016 (não-divulgação do §133); equivalentes em outras jurisdições dos 14 Eyes — incluem cláusulas de não-divulgação que impedem o destinatário de uma ordem de falar sobre ela. Essas cláusulas impõem o silêncio. Elas não, na maioria das jurisdições, obrigam o destinatário a fazer ativamente uma declaração afirmativa falsa.

É essa distinção que o canary explora. Um provedor publica "não recebemos uma NSL até [data]" numa cadência fixa — semanal, mensal, trimestral. Enquanto a declaração permanecer verdadeira, a publicação continua. Se o provedor receber uma ordem, não pode dizê-lo diretamente (gag order). Mas pode parar de publicar a declaração afirmativa. O próximo canary agendado ou não aparece, ou aparece com a cláusula relevante removida, ou aparece com linguagem diferente. Essa ausência — essa mudança — é informação que a gag order não consegue suprimir.

O canary da BitVPS, publicado em /canary/, segue este padrão. Toda segunda-feira reassinamos uma declaração que cobre a semana encerrada no domingo anterior. A declaração assinada enumera: NSLs recebidas (meta: zero), gag orders recebidas (meta: zero), ordens de retenção em massa recebidas (meta: zero), contagens de ordens por jurisdição (São Cristóvão e Nevis, Islândia, Países Baixos, Roménia, Suíça), notificações DMCA recebidas versus atendidas, e queixas de abuso recebidas versus atendidas. Espera-se que cinco dos seis números sejam zero numa semana normal; os números de abuso e DMCA são diferentes de zero por design (recebemos queixas de abuso e publicamos quantas).

A cadência importa. Um canary publicado uma vez por ano carrega menos sinal do que um publicado semanalmente — o atraso entre a coação e o cliente notá-la é a janela de frescor. Canaries semanais reduzem essa janela para sete dias; canaries diários (raros, porque exigem manejo de chaves em escala) reduzem-na para vinte e quatro horas. Canaries trimestrais deixam uma janela de três meses na qual um provedor poderia ser comprometido antes que qualquer observador externo notasse.

Verificação PGP

Verificando um canary assinado com PGP — quatro etapas

Um canary que não está assinado criptograficamente é teatro. A verificação leva quatro passos e cerca de noventa segundos. O exemplo abaixo usa o canary da BitVPS; o mesmo procedimento funciona para qualquer provedor que publique um canary assinado em PGP.

Etapa 1 — Obtenha a chave pública do provedor. A BitVPS publica a chave pública PGP em /pgp/. A impressão digital da chave está documentada em várias páginas do site (about, canary, pgp, rodapé), de modo que uma tentativa de adulteração de uma única página seja detectável. Cruze a impressão digital com várias fontes — snapshots do archive.org, a Wayback Machine, keyservers PGP de terceiros — antes de confiar nela.

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

Etapa 2 — Importe a chave. Importe para o seu chaveiro GnuPG local. A chave permanece no seu armazenamento local — nenhum upload é necessário, nenhuma confiança em terceiros é necessária.

gpg --import bitvps-pubkey.asc

Etapa 3 — Baixe o texto do canary assinado. O canary em /canary/ é HTML renderizado, mas o arquivo assinado subjacente também está disponível como um .asc clearsigned — visível no fim da página do canary ou diretamente pelo caminho de armazenamento. Para os fins deste exemplo, salve-o como canary.asc no seu diretório de trabalho.

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

Etapa 4 — Verifique a assinatura. Execute gpg --verify no arquivo .asc. Uma linha "Good signature" confirma duas coisas: o canary foi assinado pelo detentor da chave importada, E o texto do canary não foi alterado desde a assinatura. Uma verificação falhada significa que o arquivo foi modificado, a assinatura é inválida ou a chave não corresponde — trate o canary como não confiável e investigue mais a fundo.

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

Se você nunca usou o GnuPG antes, instale-o primeiro: `apt install gnupg2` em Linux da família Debian, `brew install gnupg` no macOS, ou baixe o GPG4Win no Windows. O passo de verificação em si é o mesmo em todas as plataformas.

Canaries ativos

Hosts e organizações que mantêm um warrant canary

Lista curta, verificável. Incluímos exemplos históricos (Apple 2013–2014, Reddit 2014–2016) para contexto — são úteis como estudos de caso de como um canary sinaliza mudança. Envie-nos adições via /panel/?section=support se você mantém um canary público não listado aqui.

Provedor / projeto	Cadência	Primeira publicação	Status	Notas
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.

Mantemos esta lista curta deliberadamente. Uma lista longa e aspiracional dilui o sinal — o valor de um canary é que ele é verificável, e a verificação em escala é cara. Atualizamos a lista quando a alteramos; o campo dateModified nesta página reflete a passagem de verificação mais recente.

Seção honesta

O que um canário faltando realmente significa?

Resposta honesta: menos do que o material de marketing dá a entender. A causa dominante de um canary perdido na última década não foi o recebimento de uma National Security Letter — foi o descuido administrativo. O engenheiro responsável estava de férias, o cron job esbarrou numa rotação de credenciais, o DNS do subdomínio do canary expirou, a empresa esqueceu. Uma única renovação perdida é fraco sinal, na melhor das hipóteses.

O que transforma sinal fraco em sinal forte é a corroboração. Procure por:

Um canário que perde sua renovação agendada e posteriormente reaparece com linguagem materialmente alterada (cláusula removida, contagem de jurisdições alterada, escopo reduzido).
Uma falha de canary que coincide com a divulgação pública de uma questão legal envolvendo o provedor.
Uma mudança de chave PGP acompanhando a interrupção do canary — especialmente se a nova chave foi publicada sem o cruzamento de impressão digital de múltiplas fontes que a chave original tinha.
Silêncio organizacional — nenhuma declaração pública explicando a interrupção, nenhum reconhecimento nas redes sociais, nenhuma resposta a consultas diretas de clientes.
Indisponibilidade súbita da própria URL do canary, especialmente se versões em cache no archive.org também forem removidas.

A remoção do canary da Apple em 2014 é o estudo de caso canônico. O relatório de transparência de setembro de 2013 continha a frase "A Apple nunca recebeu uma ordem sob a Seção 215 do USA Patriot Act." O relatório de transparência de setembro de 2014 não continha. A Apple não emitiu nenhuma declaração pública explicando a mudança. Pesquisadores de privacidade (Christopher Soghoian, então na ACLU; Glenn Greenwald no The Intercept) sinalizaram a ausência em poucos dias. O sinal foi fraco no início — poderia ter sido uma mudança editorial — mas a ausência persistiu nos relatórios subsequentes, e o conselho-geral da Apple não voltou a reafirmar a declaração do canary quando questionado diretamente. Dois anos depois, a interpretação consensual na comunidade de pesquisa em privacidade era que a Apple havia recebido uma ordem da Seção 215. A Apple nunca confirmou nem negou isso.

A interpretação correta de um canary perdido é "investigue mais a fundo", não "o provedor foi intimado". Os canaries são evidência na ausência de engano, não prova na sua presença.

Limites

Limitações dos canaries como sinal

Três limites honestos que você deve ponderar antes de tratar um canary como prova criptográfica da integridade de um provedor.

1. A teoria jurídica depende de uma brecha. O canary explora uma doutrina segundo a qual as gag orders impõem o silêncio em vez de uma falsidade afirmativa. Essa doutrina não foi testada definitivamente para todos os estatutos de vigilância em todas as jurisdições. A Stanford Law Review e outros juristas argumentaram de ambos os lados. Um promotor determinado poderia plausivelmente argumentar que obrigar a publicação afirmativa contínua de "não recebemos" é ela própria parte de uma obrigação de não-divulgação, e que cessar a publicação é uma violação da gag. A teoria legal sustentou-se até agora na jurisprudência publicada dos EUA, mas não foi litigada até uma resolução definitiva. Outras jurisdições estão ainda menos testadas.

2. Canários sem assinatura são inúteis. Um canary que não está assinado com uma chave PGP verificável — ou que usa uma chave cuja impressão digital não pode ser cruzada com várias fontes independentes — é teatro. Um adversário que controla o site do provedor pode substituir um canary forjado de "está tudo bem" e não há como detectar a substituição. A assinatura PGP é o que torna o canary determinante. Texto não assinado não é um canary, não importa o que diga. Verifique antes de confiar.

3. Canários vencidos são ambíguos. Quando um canary deixa de ser renovado, a interpretação depende do que mais está acontecendo. Um canary expirado mais silêncio organizacional mais uma mudança de chave é um sinal forte. Um canary expirado sozinho é fraco — pode significar que o engenheiro está de férias. Um canary que nunca começou não é sinal nenhum. O ônus da desambiguação recai sobre o cliente; o provedor só pode honestamente publicar o que pode honestamente publicar.

Trate os canaries como um sinal de integridade cultural entre vários, não como uma garantia de segurança. Um canary diz a você que um provedor considera a coação um risco real o suficiente para investir esforço de engenharia em pré-publicar o sinal de contradição. Isso é significativo. Não é a mesma coisa que prova criptográfica.

Perguntas Frequentes

Warrant canary — perguntas frequentes

O que é um 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.

Citações

Fontes em que nos baseamos

Veja o canary ao vivo — verificado semanalmente.

A BitVPS reassina o canary toda segunda-feira. A declaração atual, o arquivo de cada semana anterior e a chave PGP para verificação estão todos em /canary/.

Veja o canary ao vivo da BitVPS Baixe a chave PGP