Кто видит конверт: метаданные в Signal, SimpleX, Session и XMPP — сравнение
Сквозное шифрование отвечает на один вопрос — может ли кто-то прочитать это сообщение в пути — и ничего не говорит о более тихом вопросе, который важен не меньше: кто видит сам факт сообщения. Метаданные доставки — время соединений, IP-адреса, идентификаторы, картина контактов — не шифруются никогда, потому что что-то должно оставаться читаемым, чтобы трафик вообще можно было маршрутизировать.
Что покрывают метаданные
Шифрование содержимого скрывает сказанное. Оно не скрывает, что устройство в определённый момент, из определённой сети связалось с сервисом и обменялось пакетом определённого размера. Одного тайминга и объёма достаточно, чтобы набросать, кто с кем и когда общается; потому архитектурные решения мессенджера насчёт метаданных значат не меньше, чем его шифры.Signal: sealed sender и минимум хранения
Signal сводит серверное хранение к минимуму и с 2018 года использует sealed sender, убирающий личность отправителя с внешней стороны каждого сообщения; собственное сравнение проекта — письмо с "a blank space where the 'from' address used to be", доставляемое при знании только адресата. Тот же текст признаёт границы: устойчивость к "traffic correlation via timing attacks and IP addresses" остаётся незавершённой работой, а устройство, пользующееся Signal, всё равно сообщает о своём соединении инфраструктуре Signal. Что реально хранит Signal, документируют не маркетинговые материалы, а правовые раскрытия. Страница правительственных запросов публикует стенограммы полученных требований; отвечая на повестку большого жюри 2016 года, компания сообщила, что единственное, что она может предоставить, — дата регистрации аккаунта и дата последнего подключения пользователя. Запросы, исполненные в 2021 году и после очередной повестки в марте 2026-го, повторяют тот же мотив: данных просто не существует на серверах Signal. Остаётся осадок, который есть у любой клиент-серверной схемы: когда вы подключались и откуда. Один структурный идентификатор остаётся: аккаунты Signal создаются на номер телефона, хотя имена пользователей теперь держат этот номер вне контактных списков других. Это привязывает каждый аккаунт к чему-то в реальном мире — важно, когда владелец не должен связываться с конкретной персоной.SimpleX: никаких пользовательских идентификаторов в сети
SimpleX бьёт по проблеме идентификаторов напрямую. Вместо аккаунтов он пересылает сообщения через очереди сообщений на каждый контакт, адреса которых — единственное, что знает сервер. Проект заявляет, что "SimpleX Chat has no user identifiers visible to the network"; профили, контакты и сообщения хранятся только на клиентских устройствах. Разговор обычно идёт через два разных релея, по одному на направление, так что ни один оператор не видит трафик в обе стороны. Есть и независимая проверка: аудит кода Trail of Bits, анонсированный в ноябре 2022 года, нашёл две уязвимости средней и две низкой тяжести в криптографической и сетевой библиотеке — ни одна не подрывает модель без идентификаторов. Серверы SimpleX видят адрес очереди и соединение с ней — во многом поэтому проект с тех пор вкладывается в приватную маршрутизацию, пряча IP отправителей от операторов релеев. Как и у любой релейной схемы, запас прочности зависит и от размера сети: очередь на малоиспользуемом сервере легче коррелировать, чем очередь в плотном трафике.Session: onion-запросы через собственную сеть
Session убирает телефон и почту из создания аккаунта: аккаунт — это свежесгенерированный случайный ID с сидом восстановления. Сообщения идут через её децентрализованную сеть как onion-запросы, наслоённые так, что, по словам проекта, "no single server ever knows a message's origin and destination". Доставка идёт через рои из пяти-семи узлов, держащих зашифрованные сообщения до получения. Документация утверждает даже, что это делает "impossible for Session to track users' IP addresses"; абсолютные заявления требуют осторожности — небольшая собственная сеть сильно зависит от целостности своих узлов.XMPP с OMEMO: шифрование без обещаний о метаданных
XMPP — федеративный случай. Стандарт OMEMO (XEP-0384) приносит в XMPP шифрование в стиле double ratchet от Signal с поддержкой нескольких устройств, считая серверы ненадёжными для содержимого. Спецификация честна насчёт границы: против "metadata and traffic analysis" она не защищает. В федеративной сети видно, кто с кем общается, — серверам, на которых лежат аккаунты, и всему на федеративном пути между ними. Выбор провайдера — решение о метаданных не меньше, чем о доступности: шифрование содержимого стандартизовано, защита метаданных — что сделает из этого оператор.Чего не убирает никто
Сравнение остаётся честным, только если заканчивается тем, что объединяет все четыре:- Signal: сервис видит время соединений и IP-адреса, регистрация привязана к номеру телефона; sealed sender прячет личность отправителя, а опубликованные раскрытия показывают, что выдаются даты регистрации и последнего подключения.
- SimpleX: релеи видят адреса очередей и соединения с ними; профили и сообщения остаются на устройствах, идентификаторов аккаунтов на уровне сети нет.
- Session: случайные ID аккаунтов, маршрутизация onion-запросов, скрывающая источник и адресата от отдельных узлов, зашифрованные сообщения временно лежат в роевых узлах.
- XMPP с OMEMO: содержимое зашифровано сквозно, но серверы и федеративные пути видят, кто с кем и когда общается.
- Все четыре: провайдер или локальная сеть всё равно видит, что устройство общается с сервисом — или с Tor, если трафик затуннелен, — а корреляция таймингов остаётся открытой проблемой всюду.