Warrant canary — это регулярно публикуемое, подписанное PGP заявление о том, что поставщик услуг не получал определённых видов юридических предписаний — чаще всего Письма национальной безопасности, приказа о неразглашении или требования массовой слежки. Canary продолжается, пока не прекращается. Отсутствие очередного запланированного canary — это сигнал о том, что что-то изменилось. Эта страница объясняет механизм, описывает проверку PGP и перечисляет провайдеров, поддерживающих canary в 2026 году.
Обновлено · Автор: Инженерная команда BitVPS
Warrant canary опирается на специфическую асимметрию в доктрине вынужденной речи. Многие законодательные акты о слежке — 18 USC §2709 в США (полномочие Письма национальной безопасности); аналогичные положения в Законе об investigatory powers Великобритании 2016 года (§133 о неразглашении); эквиваленты в других юрисдикциях 14 Eyes — содержат оговорки о неразглашении, препятствующие получателю приказа говорить о нём. Эти оговорки принуждают к молчанию. В большинстве юрисдикций они не принуждают получателя активно делать ложное утверждение.
Именно это различие использует канарейка. Провайдер публикует «по состоянию на [дату] мы не получали NSL» с фиксированной периодичностью — еженедельно, ежемесячно, ежеквартально. Пока утверждение остаётся истинным, публикация продолжается. Если провайдер получает приказ, он не может сказать об этом напрямую (приказ о неразглашении). Но он может перестать публиковать утвердительное заявление. Очередная плановая канарейка либо не появляется, либо появляется с удалённым соответствующим пунктом, либо появляется с другой формулировкой. Это отсутствие — это изменение — и есть информация, которую приказ о неразглашении не может подавить.
Canary BitVPS, публикуемый по адресу /canary/, следует этому шаблону. Каждый понедельник мы повторно подписываем заявление, охватывающее неделю, заканчивающуюся предшествующим воскресеньем. Подписанное заявление перечисляет: полученные NSL (цель: ноль), полученные приказы о неразглашении (цель: ноль), полученные приказы о массовом хранении (цель: ноль), количество приказов по юрисдикциям (Сент-Китс и Невис, Исландия, Нидерланды, Румыния, Швейцария), полученные vs. исполненные DMCA-уведомления и полученные vs. исполненные жалобы на злоупотребления. Пять из шести чисел ожидаются нулевыми в обычную неделю; числа злоупотреблений и DMCA ненулевые по замыслу (мы получаем жалобы и публикуем их количество).
Периодичность важна. Canary, публикуемый раз в год, несёт меньше сигнала, чем публикуемый еженедельно — задержка между принуждением и тем, когда клиент это замечает, является окном актуальности. Еженедельные canary сокращают это окно до семи дней; ежедневные (редкие, поскольку требуют работы с ключами в масштабе) — до двадцати четырёх часов. Ежеквартальные canary оставляют трёхмесячное окно, в течение которого провайдер может быть скомпрометирован до того, как это заметит какой-либо внешний наблюдатель.
Canary, не подписанный криптографически, — это театр. Проверка занимает четыре шага и около девяноста секунд. Пример ниже использует canary BitVPS; та же процедура работает для любого провайдера, публикующего canary, подписанный PGP.
Шаг 1 — Получите публичный ключ от провайдера. BitVPS публикует публичный PGP-ключ по адресу /pgp/. Отпечаток ключа задокументирован на нескольких страницах сайта (about, canary, pgp, footer), поэтому попытка подделки одной страницы обнаруживаема. Сверяйте отпечаток с несколькими источниками — снимками archive.org, машиной Wayback, сторонними PGP-серверами ключей — прежде чем доверять ему.
curl -O https://bitvps.io/pgp/bitvps-pubkey.asc
gpg --show-keys bitvps-pubkey.asc
Шаг 2 — Импортируйте ключ. Импортируйте в локальный keyring GnuPG. Ключ остаётся в локальном хранилище — загрузка не требуется, доверие третьим сторонам не нужно.
gpg --import bitvps-pubkey.asc
Шаг 3 — Скачайте подписанный текст canary. Canary по адресу /canary/ отображается как HTML, но нижележащий подписанный файл также доступен как clearsigned .asc — виден внизу страницы canary или напрямую по пути хранения. Для целей этого примера сохраните его как canary.asc в Вашем рабочем каталоге.
curl -O https://bitvps.io/canary/latest.asc
Шаг 4 — Проверьте подпись. Запустите gpg --verify против файла .asc. Строка «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, сначала установите его: apt install gnupg2 на Linux-семействе Debian, brew install gnupg на macOS или загрузите GPG4Win для Windows. Сам шаг верификации одинаков на каждой платформе.
Краткий список, поддающийся проверке. Мы включили исторические примеры (Apple 2013–2014, Reddit 2014–2016) для контекста — они полезны как кейс-стади о том, как canary сигнализирует об изменениях. Присылайте дополнения через /panel/?section=support, если Вы поддерживаете публичный canary, которого здесь нет.
| Провайдер / проект | Периодичность | Впервые опубликовано | Статус | Примечания |
|---|---|---|---|---|
| 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 в прошлом десятилетии был не факт получения Письма национальной безопасности — ею была административная халатность. Ответственный инженер был в отпуске, cron-задача столкнулась с ротацией учётных данных, DNS для поддомена canary истёк, компания забыла. Единственный пропущенный срок продления — слабый сигнал в лучшем случае.
Слабый сигнал превращается в сильный за счёт подтверждения. Ищите:
Удаление канарейки Apple в 2014 году — канонический пример. Отчёт о прозрачности за сентябрь 2013 года содержал строку «Apple никогда не получала приказа по Разделу 215 USA Patriot Act». Отчёт о прозрачности за сентябрь 2014 года — нет. Apple не выпустила публичного заявления, объясняющего изменение. Исследователи приватности (Кристофер Согоян, тогда в ACLU; Гленн Гринвальд из The Intercept) отметили это отсутствие в течение нескольких дней. Поначалу сигнал был слабым — это могло быть редакторское изменение, — но отсутствие сохранялось в последующих отчётах, и главный юрист Apple впоследствии не подтвердил заявление канарейки при прямом вопросе. Два года спустя в сообществе исследователей приватности сложился консенсус, что Apple получила приказ по Разделу 215. Apple так и не подтвердила и не опровергла это.
Правильная интерпретация пропущенного canary — «исследовать дальше», а не «провайдеру вручили требование». Warrant canary — это улика при отсутствии обмана, а не доказательство при его наличии.
Три честных ограничения, которые стоит взвесить, прежде чем считать warrant canary криптографическим доказательством целостности провайдера.
1. Юридическая теория зависит от лазеек. Канарейка использует доктрину, согласно которой приказы о неразглашении принуждают к молчанию, а не к утвердительной лжи. Эта доктрина не была окончательно проверена для каждого закона о слежке в каждой юрисдикции. Stanford Law Review и другие правоведы аргументировали обе стороны. Решительный прокурор мог бы правдоподобно утверждать, что принуждение к продолжению утвердительной публикации «мы не получали» само является частью обязательства о неразглашении, а прекращение публикации — нарушением запрета. Эта правовая теория пока выдерживала в опубликованной судебной практике США, но не была доведена до окончательного разрешения в суде. Другие юрисдикции проверены ещё меньше.
2. Неподписанные warrant canary бесполезны. Канарейка, не подписанная проверяемым PGP-ключом — или использующая ключ, чей отпечаток нельзя сверить с несколькими независимыми источниками, — это театр. Противник, контролирующий сайт провайдера, может подменить её на поддельную канарейку «всё хорошо», и обнаружить подмену будет невозможно. Именно PGP-подпись делает канарейку несущей. Неподписанный текст — это не канарейка, что бы в нём ни говорилось. Проверяйте, прежде чем доверять.
3. Просроченные warrant canary неоднозначны. Когда canary перестаёт обновляться, интерпретация зависит от того, что ещё происходит. Просроченный canary плюс организационное молчание плюс смена ключа — сильный сигнал. Просроченный canary сам по себе — слабый: это может означать, что инженер в отпуске. Canary, который так и не был запущен, — вообще не сигнал. Бремя устранения неоднозначности лежит на клиенте; провайдер может честно публиковать только то, что он может честно публиковать.
Относитесь к canary как к одному из нескольких сигналов культурной целостности, а не как к гарантии безопасности. Canary сообщает Вам, что провайдер считает принуждение достаточно реальным риском, чтобы вкладывать инженерные усилия в предварительную публикацию противоречащего сигнала. Это значимо. Это не то же самое, что криптографическое доказательство.
BitVPS переподписывает warrant canary каждый понедельник. Текущее заявление, архив всех предыдущих недель и PGP-ключ для проверки — всё на /canary/.