¿Qué es un warrant canary, y por qué importa?

Un warrant canary es una declaración publicada con regularidad y firmada con PGP que indica que un proveedor de servicios no ha recibido ciertos tipos de procedimientos legales — habitualmente una National Security Letter, una orden de silencio o una demanda de vigilancia masiva. El canario continúa hasta que se detiene. La ausencia del siguiente canario programado es la señal de que algo ha cambiado. Esta página explica el mecanismo, recorre la verificación PGP y enumera los proveedores que mantienen uno en 2026.

Actualizado 2026-05-03 · Autor: Ingeniería de BitVPS

Ver el warrant canary en vivo de BitVPS → Cómo verificar un canary

Mecanismo

Cómo funciona un warrant canary — la lógica jurídica

El warrant canary depende de una asimetría concreta en la doctrina del discurso forzado. Muchas leyes de vigilancia —18 USC §2709 en los Estados Unidos (la autoridad de las Cartas de Seguridad Nacional); disposiciones análogas en la Ley de Poderes de Investigación del Reino Unido de 2016 (la prohibición de divulgación del §133); equivalentes en otras jurisdicciones 14-Eyes— incluyen cláusulas de no divulgación que impiden al destinatario de una orden hablar de ella. Esas cláusulas obligan al silencio. En la mayoría de jurisdicciones no obligan al destinatario a emitir activamente una declaración afirmativa falsa.

Esa distinción es lo que explota el canary. Un proveedor publica "no hemos recibido ninguna NSL a fecha de [fecha]" con una cadencia fija: semanal, mensual, trimestral. Mientras la afirmación siga siendo cierta, la publicación continúa. Si el proveedor recibe una orden, no puede decirlo directamente (orden de silencio). Pero sí puede dejar de publicar la afirmación positiva. El siguiente canary programado, o bien no aparece, o aparece con la cláusula pertinente eliminada, o aparece con un texto distinto. Esa ausencia —ese cambio— es información que la orden de silencio no puede suprimir.

El canary de BitVPS, publicado en /canary/, sigue este patrón. Cada lunes volvemos a firmar una declaración que cubre la semana que termina el domingo anterior. La declaración firmada enumera: NSL recibidas (objetivo: cero), órdenes de silencio recibidas (objetivo: cero), órdenes de retención masiva recibidas (objetivo: cero), recuentos de órdenes por jurisdicción (San Cristóbal y Nieves, Islandia, Países Bajos, Rumanía, Suiza), avisos DMCA recibidos frente a los tramitados, y quejas de abuso recibidas frente a las tramitadas. Se espera que cinco de las seis cifras sean cero en una semana normal; las cifras de abuso y DMCA son distintas de cero por diseño (recibimos quejas de abuso y publicamos cuántas).

La cadencia importa. Un canary publicado una vez al año transmite menos señal que uno publicado semanalmente: el desfase entre la coerción y el momento en que el cliente lo nota es la ventana de frescura. Los canaries semanales reducen esa ventana a siete días; los diarios (poco comunes, porque requieren manejo de claves a escala) la reducen a veinticuatro horas. Los canaries trimestrales dejan una ventana de tres meses durante la cual un proveedor podría verse comprometido antes de que ningún observador externo lo note.

Verificación PGP

Verificar un warrant canary firmado con PGP — cuatro pasos

Un canary que no está firmado criptográficamente es puro teatro. La verificación consta de cuatro pasos y lleva unos noventa segundos. El ejemplo siguiente utiliza el canary de BitVPS; el mismo procedimiento sirve para cualquier proveedor que publique un canary firmado con PGP.

Paso 1 — Obtén la clave pública del proveedor. BitVPS publica la clave pública PGP en /pgp/. La huella digital de la clave está documentada en varias páginas del sitio web (about, canary, pgp, footer), de modo que un intento de manipulación en una sola página resulta detectable. Contrasta la huella digital con múltiples fuentes —instantáneas de archive.org, la Wayback Machine, servidores de claves PGP de terceros— antes de confiar en ella.

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

Paso 2 — Importa la clave. Impórtala a tu llavero local de GnuPG. La clave permanece en tu almacén local: no hace falta subirla a ningún sitio ni depender de la confianza de terceros.

gpg --import bitvps-pubkey.asc

Paso 3 — Descarga el texto del canario firmado. El canary en /canary/ es HTML renderizado, pero el archivo firmado subyacente también está disponible como un .asc con firma en claro (clearsigned), visible al pie de la página del canary o directamente a través de la ruta de almacenamiento. Para los fines de este ejemplo, guárdalo como canary.asc en tu directorio de trabajo.

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

Paso 4 — Verifica la firma. Ejecuta gpg --verify sobre el archivo .asc. Una línea "Good signature" confirma dos cosas: que el canary fue firmado por el poseedor de la clave importada Y que el texto del canary no ha sido alterado desde la firma. Una verificación fallida significa que el archivo ha sido modificado, que la firma no es válida o que la clave no coincide: trata el canary como no fiable e investiga más a fondo.

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

Si no has usado GnuPG antes, instálalo primero: `apt install gnupg2` en Linux de la familia Debian, `brew install gnupg` en macOS, o descarga GPG4Win en Windows. El paso de verificación en sí es el mismo en todas las plataformas.

Canarios activos

Hosts y organizaciones que mantienen un warrant canary

Lista corta y verificable. Hemos incluido ejemplos históricos (Apple 2013–2014, Reddit 2014–2016) para contextualizar — son útiles como estudios de caso sobre cómo un canario señala un cambio. Envíanos aportaciones a través de /panel/?section=support si mantienes un canario público que no aparezca aquí.

Proveedor / proyecto	Cadencia	Primera publicación	Estado	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.

Mantenemos esta lista deliberadamente corta. Una lista larga y aspiracional diluye la señal: el valor de un canary radica en que sea verificable, y la verificación a gran escala resulta costosa. Actualizamos la lista cuando la cambiamos; el campo dateModified de esta página refleja la verificación más reciente.

Sección honesta

Qué significa un canary ausente significa realmente?

Respuesta honesta: menos de lo que sugiere el discurso de marketing. La causa predominante de un canary no renovado en la última década no ha sido la recepción de una National Security Letter, sino un descuido administrativo. El ingeniero responsable estaba de vacaciones, el cron job coincidió con una rotación de credenciales, el DNS del subdominio del canary caducó, la empresa se olvidó. Una sola renovación omitida es débil señal en el mejor de los casos.

Lo que convierte una señal débil en fuerte es la corroboración. Busca:

Un canary que omite su renovación programada y aparece posteriormente con un lenguaje materialmente alterado (cláusula eliminada, conteo de jurisdicciones cambiado, alcance reducido).
Un fallo de warrant canary que coincide con la cobertura pública de un asunto legal que afecta al proveedor.
Un cambio de clave PGP que acompaña a la interrupción del canary, especialmente si la nueva clave se publicó sin el contraste de huella digital de múltiples fuentes que sí tenía la clave original.
Silencio organizacional: ninguna declaración pública que explique la interrupción, ningún reconocimiento en redes sociales, ninguna respuesta a las consultas directas de los clientes.
Indisponibilidad repentina de la propia URL del canary, especialmente si las versiones cacheadas en archive.org también se eliminan.

La retirada del canary de Apple en 2014 es el caso de estudio canónico. El informe de transparencia de septiembre de 2013 contenía la frase "Apple has never received an order under Section 215 of the USA Patriot Act." El informe de transparencia de septiembre de 2014 no la contenía. Apple no emitió ninguna declaración pública que explicara el cambio. Investigadores de privacidad (Christopher Soghoian, entonces en la ACLU; Glenn Greenwald en The Intercept) señalaron la ausencia en cuestión de días. La señal fue débil al principio —podría haber sido un cambio editorial—, pero la ausencia se mantuvo en los informes posteriores, y el asesor jurídico general de Apple no reafirmó después la declaración del canary cuando se le preguntó directamente. Dos años más tarde, la interpretación consensuada en la comunidad de investigación sobre privacidad era que Apple había recibido una orden bajo la Sección 215. Apple nunca lo ha confirmado ni desmentido.

La interpretación correcta de un canary no renovado es "investigar más a fondo", no "el proveedor ha recibido una orden". Los canaries son una prueba en ausencia de engaño, no una prueba en presencia de él.

Límites

Limitaciones de los canarios como señal

Tres límites honestos a sopesar antes de tratar un canary como prueba criptográfica de la integridad del proveedor.

1. La teoría legal depende de un vacío legal. El canary explota una doctrina según la cual las órdenes de silencio (gag orders) obligan al silencio en lugar de a una falsedad afirmativa. Esa doctrina no se ha puesto a prueba de forma definitiva para cada ley de vigilancia en cada jurisdicción. La Stanford Law Review y otros juristas han defendido ambas posturas. Un fiscal decidido podría argumentar de forma plausible que obligar a la publicación afirmativa y continuada de "no hemos recibido" forma parte en sí misma de una obligación de no divulgación, y que cesar la publicación constituye un incumplimiento de la orden de silencio. La teoría jurídica se ha sostenido hasta ahora en la jurisprudencia estadounidense publicada, pero no se ha litigado hasta una resolución definitiva. Otras jurisdicciones están aún menos probadas.

2. Los canaries sin firmar son inútiles. Un canary que no está firmado con una clave PGP verificable —o que utiliza una clave cuya huella digital no puede contrastarse con múltiples fuentes independientes— es puro teatro. Un adversario que controle el sitio web del proveedor puede sustituirlo por un canary falsificado de "todo va bien" sin que haya forma de detectar la sustitución. La firma PGP es lo que hace que el canary tenga valor probatorio. El texto sin firmar no es un canary, diga lo que diga. Verifica antes de confiar.

3. Los canaries caducados son ambiguos. Cuando un canary deja de renovarse, la interpretación depende de qué más esté ocurriendo. Un canary caducado más silencio organizacional más un cambio de clave constituyen una señal fuerte. Un canary caducado por sí solo es una señal débil: podría significar que el ingeniero está de vacaciones. Un canary que nunca empezó no es señal alguna. La carga de desambiguar recae en el cliente; el proveedor solo puede publicar honestamente lo que honestamente puede publicar.

Considera los canaries como una señal más de integridad cultural entre varias, no como una garantía de seguridad. Un canary te dice que un proveedor considera que la coacción es un riesgo lo bastante real como para invertir esfuerzo de ingeniería en pre-publicar la señal de contradicción. Eso es significativo. No es lo mismo que una prueba criptográfica.

Preguntas frecuentes

Warrant canary — preguntas frecuentes

¿Qué es un canario de garantías?

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.

Fuentes

Fuentes en las que nos hemos apoyado

Ver el canario en vivo — verificado semanalmente.

BitVPS vuelve a firmar el canario cada lunes. La declaración actual, el archivo de cada semana anterior y la clave PGP para verificación están todos en /canary/.

Ver el warrant canary en vivo de BitVPS Descargar la clave PGP