Session: мессенджер, у которого нечего отдавать спецслужбам

Чтобы получить доступ к переписке, государству обычно не нужно взламывать шифрование. Достаточно прийти к тому, у кого хранятся данные, — к владельцу серверов. Такие серверы есть почти у всех мессенджеров, даже у тех, что гордятся сквозным шифрованием: например, в WhatsApp переписку прочитать нельзя, но метаданные — кто, с кем и когда общался, — известны Meta (признана в РФ экстремистской организацией и запрещена) и выдаются по запросу властей. Мессенджер Session устроен так, что приходить попросту не к кому. Именно поэтому осенью 2024 года его заблокировали в России.

Session не требует для регистрации номер телефона или адрес электронной почты, не имеет центральных серверов и не хранит сведения о том, кто кому пишет. Здесь нет ни имени пользователя, ни учётной записи в привычном смысле, ни регистрации: вместо аккаунта на чьём-то сервере у вас криптографический ключ, который создаётся прямо на устройстве и хранится только у вас.

Сообщения в Session не идут от вас напрямую к адресату. Они проходят через сеть из нескольких тысяч независимых серверов по всему миру (Service Nodes), причём каждое сообщение упаковывается в три слоя шифрования и передаётся через три случайно выбранных узла, ни один из которых не знает одновременно ни отправителя, ни получателя. Это та же логика, по которой работает Tor, но реализованная в виде отдельной сети, заточенной именно под мессенджер.

Сами серверы тоже не знают, что передают: они видят только зашифрованный трафик, который раскрывается лишь в конечной точке. И что важнее — отдать переписку по запросу государства просто некому: не потому что разработчики отказываются, а потому что это технически невозможно. Расшифрованных сообщений на серверах нет, ключей пользователей у создателей нет, связки «номер телефона — аккаунт» не существует.

В сентябре 2024 года Московский городской суд вынес решение о блокировке Session на территории Российской Федерации. В одном пакете с ним заблокировали Briar, SimpleX Chat и Verum. Юридическое основание было сформулировано стандартно: невыполнение требований российского законодательства об «организаторах распространения информации» (ФЗ-149, статья 10.1) и пакета Яровой (ФЗ-374). Технически это означало, что Session не зарегистрировался в реестре ОРИ, не подключился к СОРМ, не предоставил ФСБ ключи для расшифровки сообщений. И, главное, — не мог бы предоставить эти ключи, даже если бы захотел. Это в значительной мере и стало причиной блокировки.

В этом посте — история мессенджера Session: откуда он взялся, как устроен внутри, почему авторы сделали его именно таким, как они переехали из Австралии в Швейцарию, чем он отличается от Signal и SimpleX, и какое отношение всё это имеет к российскому пользователю сегодня.

I. Контекст: что значит «защищённый мессенджер» в 2026 году

Защищённые мессенджеры можно разделить на несколько уровней — по тому, насколько в них вообще есть что выдать государству по запросу.

Уровень 1: классический мессенджер с e2e-шифрованием на серверах компании. WhatsApp, Telegram (только в секретных чатах), iMessage, Wire. У них есть центральные серверы, которые знают, что вы общаетесь с конкретным человеком (метаданные), и которые регулируются законодательством стран, где они находятся. Содержимое переписки они в e2e-режиме не видят, но факт переписки и список контактов — видят. По запросу государственных органов часть этих данных раскрывается.

Уровень 2: открытый протокол и серверы, которые хранят минимум метаданных. Самый яркий представитель — Signal. Серверы у него тоже центральные, их держит американский Signal Foundation. Разница с первым уровнем не в том, кому принадлежат серверы, а в том, что они сознательно минимизируют информацию о пользователях: контакты на них не хранятся в открытом виде, содержимое переписки — тоже. Однако сами серверы знают, кто и когда подключался к ним, а регистрация привязана к номеру телефона, и это главная претензия к Signal у тех, кому нужна максимальная анонимность. По запросу государства Signal может предоставить только дату регистрации и дату последнего подключения — но и этого, в принципе, может оказаться достаточно для слежки.

Уровень 3: децентрализованные мессенджеры без центральных серверов. Сюда относятся Matrix (как протокол с федерацией серверов), SimpleX Chat (без идентификаторов вообще, каждый разговор имеет свой релейный узел), Briar (peer-to-peer через Tor и Bluetooth) и Session. Эти системы устроены так, что нет единого центра, к которому можно было бы предъявить запрос на выдачу переписок или метаданных. Технически они либо распределённые, либо peer-to-peer.

Уровень 4: мессенджеры, в которых даже метаданные не должны протекать наружу. Это уже исследовательская территория: Cwtch (от Open Privacy Research Society), Berty, Briar в режиме офлайн через Bluetooth. Они жертвуют удобством ради максимальной анонимности.

Session находится на стыке третьего и четвёртого уровней. У него есть распределённая сеть узлов, но содержимое и метаданные защищены агрессивнее, чем у большинства децентрализованных мессенджеров. И при этом он сохраняет приемлемое удобство использования — приложение выглядит как WhatsApp, и в этом, пожалуй, главное его достоинство.

II. Loki Project, Австралия, 2018–2019: откуда взялся Session

История Session начинается в Австралии, в Мельбурне, в конце 2010-х. Несколько разработчиков и борцов за цифровую приватность — среди них Ки Джефферис (Kee Jefferys), Алекс Линтон (Alex Linton) и небольшая команда — запустили проект под названием Loki. Это был не мессенджер, а в первую очередь криптовалюта с фокусом на приватность, аналог Monero и Zcash. Loki использовал тот же протокол, что и Monero (CryptoNote/RingCT), но добавил поверх него сеть так называемых сервисных узлов (Service Nodes) — серверов, которые за вознаграждение в монетах Loki предоставляли криптографические услуги.

Service Nodes в Loki не были просто майнерами. Они выполняли вторую функцию — обеспечивали сеть Lokinet: децентрализованную onion-сеть, концептуально похожую на Tor, но с собственной инфраструктурой и встроенными экономическими стимулами. То есть чтобы запустить узел Lokinet, нужно заблокировать (застейкать) некоторое количество Loki-монет. За работу узла оператор получает вознаграждение в тех же монетах. Если узел работает плохо, залог теряется. Таким образом, сеть из узлов поддерживала сама себя без необходимости в благотворительности или университетских грантах, как в случае Tor.

В 2018 году у команды появилась идея: раз у нас уже есть распределённая сеть, обеспечивающая анонимный транспорт, почему бы не сделать поверх неё мессенджер? Это решало одну из главных проблем приватных мессенджеров — необходимость в центральной инфраструктуре, подконтрольной владельцу. Если транспорт обеспечивает peer-to-peer сеть узлов, которые экономически стимулированы выполнять работу, центральный сервер мессенджеру не нужен.

В 2019 году вышла первая версия мессенджера под названием Loki Messenger. Это был форк Signal Messenger, в котором заменили транспортный слой: вместо центральных серверов Signal Foundation сообщения шли через Lokinet. Идентификация пользователей тоже была заменена: вместо номера телефона использовался публичный ключ Curve25519, который и становился «именем» в сети.

Loki Messenger получил быстрое распространение в кругах, заинтересованных в максимальной приватности, — у журналистов, у активистов в авторитарных странах, у энтузиастов криптовалют. Но название «Loki» создавало путаницу: люди не понимали, мессенджер это или криптовалюта.

В январе 2020 года проект провёл ребрендинг. Криптовалюта осталась под именем Oxen (бык по-английски, продолжая «животную» традицию криптопроектов), а мессенджер получил отдельное имя — Session. С этого момента у проекта появился самостоятельный бренд и собственная стратегия развития.

III. Архитектура: децентрализованная сеть Service Nodes

Чтобы понять, чем Session так отличается от Signal, нужно разобрать его архитектуру по слоям.

Service Nodes

Основа Session — сеть сервисных узлов. Это серверы, которые поддерживают независимые операторы по всему миру. На лето 2025 года в сети их было около 1 800. Они расположены в США, Европе, Азии, Латинской Америке. Каждый узел работает на стандартном Linux-сервере. Требования к железу относительно скромные, можно поднять на VPS за пятнадцать-двадцать долларов в месяц.

Чтобы стать оператором Service Node, нужно заблокировать некоторое количество монет нативного токена сети (сначала был LOKI, потом OXEN, с 2025 года — токен сети Session). Размер залога подбирается так, чтобы Sybil-атака (создание тысяч фейковых узлов одним актором) была экономически невыгодной. Оператор честно работающего узла получает регулярное вознаграждение в токенах. Нарушитель теряет залог.

Сеть узлов делает несколько вещей:

1. Транспортирует onion-запросы для приватной маршрутизации.
2. Хранит сообщения, которые не были немедленно доставлены (например, когда получатель оффлайн).
3. Координирует обновления списка узлов (какой узел работает, какой нет, какие у него ключи).

Onion-маршрутизация: три прыжка

Когда вы отправляете сообщение в Session, оно не идёт напрямую от вашего устройства к серверу получателя. Вместо этого ваш клиент:

1. Выбирает три случайных сервисных узла из общего списка.
2. Заворачивает сообщение в три слоя шифрования, по слою на каждый узел. Каждый слой шифруется публичным ключом X25519 соответствующего узла.
3. Отправляет получившуюся «луковицу» первому узлу.

Первый узел расшифровывает свой слой и видит только адрес следующего (второго) узла. Содержимое следующих слоёв ему недоступно. Он передаёт оставшееся второму. Второй так же снимает свой слой и видит адрес третьего. Третий снимает последний слой и доставляет сообщение в swarm — небольшую группу узлов, ответственных за хранение сообщений для получателя.

В итоге:

• Первый узел знает: ваш IP-адрес и адрес второго узла. Содержимое и конечного получателя — нет.
• Второй узел знает: адрес первого и третьего узлов. Не знает ни вас, ни получателя.
• Третий узел знает: адрес второго узла, swarm получателя и зашифрованное (e2e) содержимое. Вас он не знает.
• Swarm получателя: хранит зашифрованное сообщение, пока получатель его не заберёт. Не знает, кто отправитель.

Принцип здесь тот же, что у Tor — три прыжка onion-маршрутизации, — но сеть отдельная, специализированная под мессенджер. Её преимущество перед Tor — встроенная экономическая мотивация узлов работать честно. Недостаток в том, что она меньше Tor по числу узлов и по географии.

Swarms: децентрализованное хранение

Когда вы офлайн, ваши сообщения нужно где-то хранить, пока вы не подключитесь. В централизованном мессенджере для этого есть сервер компании, в Session — swarm.

Swarm — это случайное подмножество всей сети, выделенное под конкретного получателя. Принадлежность к swarm определяется детерминированно: по хешу вашего Session ID вычисляется, какие узлы хранят ваши сообщения. Узлы swarm дублируют сообщения между собой, чтобы данные не потерялись при выходе одного из них из сети.

Когда вы заходите в Session, ваш клиент опрашивает свой swarm: «есть для меня новые сообщения?» — и забирает их.

В этой схеме хранение распределённое и без единой точки отказа. Никакой Service Node не имеет всей картины: даже swarm видит только зашифрованные сообщения, отправителя не знает.

Криптография: ничего нового, но всё аккуратно

С точки зрения криптографии Session использует стандартный набор:

• X25519 (Diffie-Hellman на эллиптической кривой Curve25519) для согласования ключей и onion-шифрования слоёв.
• AES-256-GCM для шифрования содержимого сообщений.
• Ed25519 для электронных подписей.
• HKDF / BLAKE2b для вывода ключей.

Всё это — стандартные, хорошо изученные примитивы. Никаких самопальных алгоритмов и экзотических решений. Это сознательный выбор: разработчики Session не пытаются изобретать криптографию, они переиспользуют проверенные алгоритмы и сосредотачиваются на архитектуре системы в целом.

В 2020 году французская компания Quarkslab провела аудит безопасности Session (отчёт опубликован в 2021-м): критических уязвимостей он не выявил, но обозначил несколько мест для улучшения — в том числе работу с самоподписанными TLS-сертификатами и сложность интерфейса верификации ключей.

IV. Session ID: отказ от номера телефона

Самое заметное отличие Session от Signal и WhatsApp — это регистрация без телефонного номера или любой другой связанной с пользователем информации.

При первом запуске приложение генерирует на вашем устройстве пару X25519-ключей. Открытая часть этой пары, в шестнадцатеричном представлении, становится вашим Session ID — последовательностью из 66 символов, начинающейся с префикса 05 (для совместимости с протоколом). Например: 05a3b91e5f...d6c7a9b3.

Чтобы добавить кого-то в контакты, нужно либо узнать его Session ID (66 символов — длинно, но можно отсканировать QR-код), либо обменяться идентификаторами через какой-то другой канал (мессенджер, e-mail, бумажку).

Что это даёт?

• Анонимность. Ваш Session ID не привязан ни к чему: ни к номеру телефона, ни к e-mail, ни к имени. Чтобы связать ID с реальным человеком, нужно либо чтобы он сам его раскрыл, либо чтобы вы получили доступ к его устройству.
• Невозможность массового сопоставления. В обычных мессенджерах ваш номер сравнивается с адресной книгой друзей, и через эти связи строятся графы. В Session такого графа в принципе не существует.
• Никакого реестра. Нет центрального сервера, где можно было бы посмотреть список всех зарегистрированных пользователей. Список пользователей — это сумма всех когда-либо использованных Session ID, которые никто не собирает в одном месте.

В чём минусы такого подхода?

• Удобство нахождения людей. В Signal или WhatsApp люди находятся по номеру телефона автоматически. В Session нужно как-то получить 66 символов случайного хеша. Это вечная проблема пользователей: «как мне дать свой Session ID другу?»
• Восстановление аккаунта. Если вы потеряли устройство, вы потеряли ключи. Восстановить аккаунт по номеру или e-mail нельзя. Поэтому при первом запуске Session показывает вам мнемоническую фразу из 13 слов (как seed-фраза в криптокошельках), и просит её сохранить. Если устройство пропадёт, эта фраза — единственный способ восстановить ваш Session ID на новом устройстве.
• Спам. Поскольку нет привязки к номеру, любой может сгенерировать тысячу Session ID и засыпать сеть сообщениями. Защиты от спама на уровне протокола нет. Она делается на уровне клиента — вы блокируете нежелательные контакты вручную.

Этот компромисс между удобством и приватностью Session решает однозначно в пользу приватности, что соответствует требованиям его целевой аудитории.

V. Session Protocol против Signal Protocol: что выкинули и почему

Изначально Session был форком Signal Messenger и использовал Signal Protocol — двойное храповое (double ratchet) шифрование с прогрессивной заменой ключей. Это стандарт индустрии: тот же протокол используется в WhatsApp, в секретных-чатах Telegram (с модификациями), в Wire.

Однако в 2020 году разработчики Session решили отказаться от Signal Protocol в пользу собственного, более простого решения, которое они назвали Session Protocol. Это спорное решение, и стоит на нём задержаться.

Signal Protocol даёт два сильных свойства:

1. Forward secrecy (опережающая секретность). Если ваш ключ скомпрометирован сегодня, прошлые сообщения остаются нерасшифрованными. Это обеспечивается тем, что ключи постоянно меняются по принципу двойного храповика (double ratchet).
2. Future secrecy / post-compromise security. Если ваш ключ скомпрометирован сегодня, после следующего обмена сообщениями ключ обновляется, и злоумышленник снова теряет доступ.

Session Protocol эти свойства частично утратил. Он использует более простую схему: каждое сообщение шифруется AES-GCM с ключом, полученным из X25519-обмена между статическими ключами отправителя и получателя. Forward secrecy в полном смысле здесь нет: если ваш приватный ключ скомпрометирован, все ранее перехваченные сообщения можно расшифровать.

Почему авторы пошли на этот компромисс? Объяснение из их официального whitepaper сводится к следующему. Signal Protocol хорошо работает в синхронных сценариях, когда оба собеседника онлайн и могут обмениваться храповыми обновлениями. В асинхронной модели Session, где сообщения хранятся в swarm узлов и могут забираться получателем спустя дни, храповый механизм усложняется: нужно как-то синхронизировать состояние, нужно учитывать множественные устройства, нужно обрабатывать пропавшие сообщения. В итоге разработчики решили, что стоит пожертвовать forward secrecy ради простоты и надёжности.

Это решение вызвало критику в сообществе. Многие считают, что Session «уронил безопасность ниже допустимого». Контраргумент Session-команды — что в их модели угроз (массовое отслеживание метаданных + анонимность пользователей) важнее защитить факт коммуникации, чем содержимое отдельных сообщений. Если злоумышленник смог украсть ваш ключ, у него есть масса других способов добраться до содержимого, и forward secrecy его не остановит.

Дискуссия об этом не закрыта. Серьёзные эксперты по криптографии (например, Matthew Green из Johns Hopkins) высказывались сдержанно-критически. Но факт остаётся фактом: Session сегодня не имеет полноценной forward secrecy в смысле Signal Protocol.

VI. Чего Session не умеет

Чтобы быть честными, нужно отметить, что Session — это компромисс не только в криптографии, но и в функциональности.

Голосовые и видеозвонки

Долгое время Session вообще не умел делать голосовые звонки. Голосовая связь в реальном времени требует низкой задержки, что плохо сочетается с тройной onion-маршрутизацией. Начиная с 2022 года в Session появилась экспериментальная функция звонков — но она работает не через сеть сервисных узлов, а через прямое peer-to-peer соединение между устройствами, и при этом ваш IP-адрес становится известен собеседнику. Это компромисс, и многие пользователи, которым важна приватность, звонки в Session не используют.

Большие группы

Групповые чаты в Session ограничены: до недавнего времени группы могли содержать максимум 100 человек (закрытые группы) или несколько тысяч (открытые сообщества, размещённые на отдельном сервере). Для сравнения, в Telegram группы — до 200 000 человек. Это связано с архитектурой: каждое сообщение в закрытой группе нужно зашифровать и отправить отдельно каждому участнику через onion-маршруты, что создаёт проблемы с производительностью.

Скорость доставки

Сообщения в Session идут не мгновенно. Onion-маршрутизация добавляет 1–3 секунды задержки. Иногда сообщения «застревают» на промежуточных узлах и доходят с заметным опозданием. Для повседневной переписки это терпимо, для оперативной связи — нет.

Удобство онбординга

Поделиться Session ID — задача нетривиальная. 66 символов в WhatsApp не передашь, по телефону их не продиктовать. В реальности люди обмениваются Session ID либо через QR-код при личной встрече, либо вставляя его в другой мессенджер. Это не запретительный барьер, но он значимый.

Поиск пользователей

Найти кого-то в Session нельзя. Нет каталога, нет поиска по имени, нет даже централизованного списка. Если вы потеряли Session ID знакомого — единственный способ его найти — попросить через другой канал.

Все эти ограничения — следствие приоритета приватности над удобством. Для целевой аудитории это нормально. Для массового использования — это серьёзные препятствия, и Session никогда не претендовал на массовость в том смысле, что её достиг WhatsApp.

VII. Деньги: токен, который никто не понимает

Один из самых необычных аспектов Session — его экономическая модель. У проекта есть собственный криптотокен (изначально LOKI, потом OXEN, с мая 2025 года — SESH), на котором держится сеть Service Nodes.

Логика такая:

1. Чтобы запустить Service Node, нужно заблокировать фиксированное количество токенов (исторически было 15 000 OXEN, точные цифры менялись).
2. Оператор узла получает регулярные выплаты в токенах за работу.
3. Если узел недобросовестен (не доставляет сообщения, не отвечает на запросы), залог частично или полностью списывается.

Эта схема реализует внутреннюю экономику сети без необходимости в благотворительности, грантах или подписках пользователей. Финансирование идёт за счёт регулярного выпуска (эмиссии) новых токенов в пользу операторов узлов — то же, что допэмиссия акций для оплаты сотрудников: запас токенов растёт, доля старых держателей размывается, но сеть продолжает работать. В теории такая модель может существовать сколь угодно долго.

На практике, однако, есть проблемы.

• Курс токена нестабилен. OXEN, как и большинство мелких криптовалют, в 2022–2024 годах терял в цене. Это означало, что выплаты операторам в долларовом эквиваленте падали, и часть узлов выключилась.
• Юридическая неопределённость. Токен формально не зарегистрирован как ценная бумага, что в США (где много операторов) создаёт регуляторные риски.
• Сложность для пользователя. Обычному пользователю Session не нужно знать про токены: он просто скачивает приложение и общается. Но для понимания того, как устроена устойчивость сети, разбираться в токеномике обязательно. Это создаёт ощущение, что Session — это «что-то связанное с криптой», что не всегда нравится пользователям, ориентированным на приватность и избегающим любого крипто-шума.

В мае 2025 года команда Session запустила собственный блокчейн (Session Network), Ethereum-совместимый, с новым токеном SESH вместо OXEN. Идея — отделить мессенджер от старой инфраструктуры токена Oxen и переехать на более гибкую платформу. Что это даст в долгосрочной перспективе, пока непонятно.

VIII. Переезд в Швейцарию: октябрь 2024

До 2024 года проект формально вёлся австралийской некоммерческой организацией — OPTF (Oxen Privacy Tech Foundation, позже Open Privacy Tech Foundation), зарегистрированной в Мельбурне. Это был неудобный юрисдикционный выбор: Австралия в 2018 году приняла Assistance and Access Act, обязывающий технологические компании по требованию правительства встраивать в свои продукты технические возможности для доступа к зашифрованным данным. Формально это закон, который позволяет правительству заставить компанию ослабить криптографию своих собственных продуктов.

В 2024 году давление на Session усилилось. По сообщениям независимого журналистского ресурса 404 Media, к одному из сотрудников OPTF приходили офицеры Австралийской федеральной полиции с расспросами о работе Session и об одном из его пользователей. Никаких правонарушений сотруднику не предъявили, но визит был воспринят командой как сигнал: оставаться в Австралии больше нельзя.

В октябре 2024 года было объявлено, что стюардство над проектом передаётся новой организации — Session Technology Foundation (STF, по-немецки Session Technology Stiftung), зарегистрированной в швейцарском городе Цуг. Президентом фонда стал Алекс Линтон, ранее работавший в OPTF.

Выбор Швейцарии не случаен. Это юрисдикция с одними из самых сильных в мире правил защиты приватности и одна из немногих стран, где формальные требования к расшифровке зашифрованных данных не предусмотрены законом. Швейцария — место регистрации Proton (ProtonMail, ProtonVPN), Threema, Tresorit и многих других проектов, ориентированных на приватность. Цуг известен как «Crypto Valley» — центр криптоэкономики Европы.

После переезда официальные репозитории на GitHub, ключи подписи и публикация в магазинах приложений перешли под управление STF. Технически для пользователя ничего не изменилось — мессенджер остался тем же. Изменился юридический владелец и набор законов, под которые попадает проект.

IX. Блокировка в России: сентябрь 2024 года

И теперь — про Россию. Это самая важная часть для российского читателя.

Блокировка Session в России была частью большой кампании Роскомнадзора 2024–2025 годов против иностранных мессенджеров. Хронология примерно такая:

• 9 августа 2024: Заблокирован Signal «за нарушение требований российского законодательства».
• Конец августа 2024: Начались проблемы с подключением к Session для пользователей из России.
• Сентябрь 2024: Московский городской суд вынес решение о блокировке четырёх мессенджеров одним пакетом: Session, Briar, SimpleX Chat и Verum.
• 13 декабря 2024: Заблокирован Viber.
• 2025: Заблокированы голосовые звонки в WhatsApp и Telegram, ограничен FaceTime, заблокирован Snapchat.
• Февраль 2026: WhatsApp исключён из российской доменной системы — без средств обхода мессенджер перестал открываться.
• Март 2026: окончательно заблокирован Telegram.

Юридические основания, на которые ссылался Роскомнадзор и которые принимал суд:

Первое. ФЗ от 27 июля 2006 года № 149-ФЗ «Об информации», статья 10.1, введённая ФЗ-97 в 2014 году. Эта статья закрепила понятие «организатор распространения информации» (ОРИ) и обязала любой сервис, через который пользователи обмениваются сообщениями, регистрироваться в специальном реестре Роскомнадзора и выполнять обязанности ОРИ: хранить метаданные, идентифицировать пользователей, предоставлять данные правоохранительным органам.

Второе. ФЗ от 6 июля 2016 года № 374-ФЗ (пакет Яровой), внёсший дополнения в статью 10.1 ФЗ-149 и в Закон о связи. Он обязал ОРИ хранить содержимое сообщений до 6 месяцев и метаданные до года, а также предоставлять ФСБ ключи для расшифровки переписки.

Третье. ФЗ от 12 августа 1995 года № 144-ФЗ «Об оперативно-розыскной деятельности», устанавливающий общую рамку, в которой государственные органы получают доступ к данным граждан.

Session не зарегистрировался в реестре ОРИ, не подключился к СОРМ, не предоставил ФСБ ключи для расшифровки. Это и стало формальным основанием для блокировки.

Однако реальная причина — глубже. Session технически не может выполнить эти требования, даже если бы команда захотела. Объясню по пунктам.

Хранить метаданные. Сеть Session устроена так, что ни один из её узлов не знает одновременно отправителя и получателя сообщения. Метаданные «кто кому когда писал» в системе физически не накапливаются. Сервер Session, который мог бы их выдать, не существует.

Идентифицировать пользователей. Session ID — это публичный криптографический ключ. Связки «ID — реальное имя — номер телефона» в системе нет. Чтобы идентифицировать пользователя, надо получить физический доступ к его устройству.

Предоставить ключи для расшифровки. Ключи генерируются на устройстве пользователя и никуда не отправляются. У Session Technology Foundation нет копии этих ключей. Передать их государству нельзя, потому что их нет.

Таким образом, требования российского законодательства в отношении Session — это требования, которые невозможно выполнить, не перестроив систему с нуля. И, поскольку Session не перестроился, его заблокировали.

Сегодня (середина 2026 года) Session в России не работает. Чтобы им пользоваться, нужно либо запустить VPN, который выводит вас за пределы российского сегмента, либо настроить Session так, чтобы он работал через Tor (такая опция в приложении есть), либо поднять собственный Service Node за пределами России и принудительно использовать его как точку входа в сеть.

X. Сравнение: Session vs Signal vs SimpleX vs Briar

Чтобы понять, где Session занимает место в ландшафте приватных мессенджеров, полезно его сравнить с ближайшими аналогами.

Signal — самый удобный, технически самый продвинутый. Привязка к номеру телефона — главное уязвимое место. Подходит для большинства задач, где нужен e2e-шифрованный мессенджер с разумной анонимностью.

Session — анонимность выше, чем у Signal, удобство ниже. Главное преимущество — отсутствие привязки к телефону и распределённая инфраструктура. Главный недостаток — упрощённая криптография без полноценной forward secrecy.

SimpleX — самая радикальная архитектура из всех (подробно я разбирал её в отдельном посте). Сложнее в настройке, но в плане метаданных лучше всех.

Briar — самый параноидальный вариант. Peer-to-peer, работает через Tor или Bluetooth напрямую (не нужен интернет в принципе). Подходит для тех ситуаций, когда сеть отрезана, но требует, чтобы оба собеседника были онлайн одновременно (асинхронная переписка через посредников возможна, но реализована сложно).

Session и SimpleX: соседи по полке с разной философией

Поскольку Session и SimpleX чаще всего рассматриваются вместе как «два самых конфиденциальных мессенджера общего пользования», стоит на них остановиться подробнее. Они решают одну и ту же задачу — максимально ограничить количество метаданных, которые могут оказаться в чужих руках, — но идут к ней с разных сторон.

Идентификатор пользователя. В Session он есть: ваш Session ID — это постоянный публичный X25519-ключ длиной 66 hex-символов. Он остаётся одним и тем же для всех ваших контактов. Кто-то один из них, скомпрометированный, теоретически может рассказать другим, что вы общаетесь под таким-то ID. В SimpleX идентификатора нет вообще. Для каждого контакта создаётся своя пара однонаправленных очередей, и нет никакого общего «вас», которого можно опознать в другом контакте. Это разные попарные псевдонимы (так их называют в академических работах по приватности) — отдельная личность под каждый разговор.

Инфраструктура. Session держится на сети из ~1 800 экономически мотивированных сервисных узлов, которые получают вознаграждение в собственном токене проекта. Сеть едина: список узлов общий для всех клиентов, и выбор маршрутов происходит из этого общего пула. У SimpleX серверов сильно меньше (десятки публичных релейных серверов), и они не образуют сеть в смысле Session: каждая очередь живёт на одном выбранном клиентом ретрансляторе. У SimpleX-команды есть несколько публичных ретрансляторов «по умолчанию», но любой пользователь может поднять свой собственный за пять минут на любом VPS — и архитектура поощряет именно это.

Маршрутизация. Session использует тройную onion-маршрутизацию через свою сеть узлов — три прыжка по аналогии с Tor. SimpleX по умолчанию — двухзвенная: входящая очередь живёт на одном ретрансляторе, исходящая — на другом, и ни один из них не видит обе стороны разговора. С 2023 года в SimpleX добавлена опция полного onion-режима для случаев, когда нужна максимальная анонимность IP-адресов.

Хранилище сообщений. В Session сообщения хранятся в swarm — небольшой группе узлов, отвечающих за конкретного получателя. Это даёт асинхронность (можно получить сообщения, когда вы зайдёте через неделю), но создаёт точку накопления для конкретного ID: ваш swarm видит, что вам пришло какое-то количество (зашифрованных) сообщений и от каких (зашифрованных) отправителей. В SimpleX хранение тоже временное, на ретрансляторе очереди, но привязки к «вам» как личности у этого хранения нет: ретранслятор видит только трафик в очередь и из очереди.

Криптография. Session использует упрощённую схему без полноценной forward secrecy — об этом я писал выше. SimpleX использует двойной храповый механизм Signal с post-quantum расширением (KEM-комбинация X25519 + Kyber 768), что даёт и forward secrecy, и устойчивость к будущим квантовым компьютерам. По чистой криптографии SimpleX строже.

Экономика. Session живёт за счёт встроенного токена SESH: операторам узлов регулярно эмитируются новые токены как вознаграждение за работу — это финансирует сеть, но размывает долю прежних держателей, как допэмиссия акций. SimpleX живёт за счёт открытого кода и добровольного хостинга ретрансляторов (плюс фонд, поддерживающий разработку). У Session это создаёт привязку к крипто-теме, что часть пользователей отпугивает. У SimpleX — зависимость от добровольцев, что в долгосрочной перспективе может означать меньшую устойчивость инфраструктуры.

Удобство использования. В обоих случаях нужно как-то передать адрес. В Session — 66 hex-символов или QR-код Session ID. В SimpleX — одноразовая ссылка-приглашение или QR-код. Субъективно SimpleX проще: ссылка короче, разовые приглашения интуитивнее. Но SimpleX требует больше настройки (выбор ретранслятора, понимание «направления» очередей), особенно если вы хотите запустить собственный ретранслятор.

Краткий вывод. Session — это «приватность через распределённую сеть с экономической мотивацией»: вы получаете удобную модель «зашёл и пишешь» при цене постоянного ID и упрощённой криптографии. SimpleX — это «приватность через отсутствие самой идеи аккаунта»: вы получаете максимальную чистоту метаданных при цене большего количества ручной настройки и меньшей зрелости звонков и групп.

Для российского пользователя выбор между ними — это не вопрос «что лучше», а вопрос модели угроз. Если вы не хотите, чтобы коммерческие службы или государство не могли построить ваш граф связей по факту наличия мессенджера — берите SimpleX, у него нет графа в принципе. Если вас беспокоит устойчивость инфраструктуры к давлению на провайдеров и блокировкам — берите Session, у него сеть больше и распределённее.

Для российского пользователя, заинтересованного в приватности, разумная стратегия — пользоваться связкой нескольких мессенджеров. Signal как ежедневный для общения с обычными контактами. Session или SimpleX как «второй контур» для разговоров, в которых анонимность критична. Briar — как страховка на случай полного отключения интернета.

XI. Практическое использование в России

Что российскому пользователю делать сегодня, если он хочет пользоваться Session?

Первое: установка. Приложение Session доступно в Google Play (не отозвано на 2026 год), в Apple App Store (тоже доступно, но регулярно бывает недоступно для российских аккаунтов из-за санкций), на сайте getsession.org (APK для Android, DMG/EXE для десктопа). Если у вас Apple ID привязан к российскому региону, скорее всего, придётся либо менять регион, либо устанавливать на macOS через DMG напрямую.

Второе: подключение. По умолчанию Session попытается подключиться к сети Service Nodes напрямую. В России это не сработает: ТСПУ блокирует трафик. Варианты:

• КВН. Подключаете, и Session начинает работать.
• Tor — в Session есть встроенная опция использовать Tor как транспорт. Включается в настройках. Скорость падает ещё больше, но работает даже без VPN.
• Свой Service Node — если у вас есть VPS за рубежом, вы можете поднять собственный узел и принудительно использовать его как точку входа. Это сложно, но даёт максимальную надёжность.

Третье: обмен Session ID. Самая практическая проблема — как передать кому-то 66 символов случайной строки. Решения:

• QR-код при личной встрече — самый надёжный способ.
• Через другой защищённый канал — например, через Signal (если он у вас обоих работает).
• На бумаге — например, распечатанный QR-код: его сканируют камерой, и не нужно вводить 66 символов руками.

Четвёртое: бэкап. Когда вы первый раз запустите Session, он покажет вам мнемоническую фразу из 13 слов. Запишите её на бумагу и положите в надёжное место (например, в банковскую ячейку — об этом я подробно писал в посте про цифровое наследство). Если вы потеряете устройство, это единственный способ восстановить ваш ID на новом.

Пятое: ожидания. Session — не замена WhatsApp. Это специализированный инструмент для случаев, когда нужны максимальная анонимность и устойчивость к давлению на провайдера. Для повседневной переписки с друзьями он избыточен. Для разговоров на чувствительные темы — оптимален.

Шестое: правовая сторона. Сам факт использования Session в России формально легален: уголовной или административной ответственности за использование заблокированных мессенджеров нет — речь именно о пользователе. А за рекламу способов обхода блокировок административная ответственность есть. Однако подключение через КВН — отдельная история. Реклама и публикация инструкций по обходу блокировок незаконны, само использование КВН формально допустимо, но законодательство быстро меняется.

XII. Финал

В большинстве разговоров о приватных мессенджерах с государственными регуляторами аргументация звучит примерно так: «давайте договоримся, как и когда мы выдаём данные пользователей». В случае с Signal этот разговор шёл и идёт: Signal Foundation действительно выдаёт минимальные метаданные по решению суда. В случае с Telegram он вылился в войну с Роскомнадзором в 2018-м, затихшую к 2020-му и снова вспыхнувшую в 2026-м — с окончательной блокировкой в марте.

В случае с Session такой разговор в принципе невозможен. Сеть сервисных узлов не подчиняется единому центру. Если завтра Швейцария примет закон, обязывающий Session Technology Foundation сотрудничать со спецслужбами, STF сможет передать только то, что у неё есть: исходный код, ключи подписи приложения, доступ к сайту. Содержимого переписок и метаданных у неё нет. Эти данные физически распределены по тысяче с лишним узлов в десятках юрисдикций, и собрать их в одну точку нельзя, не перестроив весь протокол.

Это, по сути, архитектурное решение политической проблемы. В мире, где всё больше стран требуют, чтобы мессенджеры дали «доступ для борьбы с терроризмом», единственный способ остаться приватным — построить систему, в которой передача доступа невозможна как класс операции. Session делает именно это.

Для российского пользователя из всего этого следует несколько простых вещей.

Первое: Session — это не запасной мессенджер «на всякий случай». Это инструмент с конкретным назначением. Используйте его, когда нужна анонимность отправителя (Session ID не привязан к телефону) и устойчивость к давлению на сервис (нет центра, на который можно давить). Для бытовой переписки используйте Signal или даже MAX, осознавая риски.

Второе: Не верьте, что какой-то один мессенджер решит вашу проблему приватности. Самый защищённый мессенджер работает на устройстве, которое может быть скомпрометировано через ОС, через приложение клавиатуры, через резервную копию iCloud, через бесконтактный считыватель отпечатков. Безопасность — это слоёный пирог, в котором мессенджер — только один слой.

Третье: Цените, что Session существует. Это редкий пример проекта, который ставит приватность пользователя выше удобства, выше функциональности, выше потенциальной прибыли. Такие проекты создаются неравнодушными людьми и держатся на их энтузиазме. Если у вас есть возможность поддержать STF — донатом, технически (запустить Service Node), или просто рассказав о Session другим — это полезно для всех.

В мире, где все мессенджеры медленно сдвигаются в сторону государственного контроля, проекты вроде Session — это не «инструмент криминалитета», как их иногда представляют. Это резервная возможность приватного общения, которая однажды может оказаться единственной альтернативой. И что бы ни происходило с регулированием в Швейцарии, в России, в Австралии, пока в мире остаётся хотя бы один узел сети, готовый передать ваше сообщение анонимно, эта возможность существует.

Дополнительное чтение

Официальные ресурсы

• getsession.org — официальный сайт проекта
• docs.oxen.io — техническая документация по архитектуре
• session.foundation — Session Technology Foundation, Швейцария
• github.com/session-foundation — официальные репозитории проекта

Технические работы

• Kee Jefferys et al. — Session: A Model for End-to-End Encrypted Conversations With Minimal Metadata Leakage. Whitepaper Session, 2020. — формальное описание протокола и архитектуры.
• Quarkslab — Audit of Session Secure Messaging Application. Технический аудит безопасности Session, 2021.

Российский правовой контекст

• ФЗ от 27 июля 2006 года № 149-ФЗ «Об информации», статья 10.1 — «Организаторы распространения информации».
• ФЗ от 6 июля 2016 года № 374-ФЗ — «пакет Яровой».
• Реестр ОРИ Роскомнадзора. — публичный реестр организаторов распространения информации (Session в нём нет).

Журналистика

• Cyberinsider — Encrypted Messenger Session Moves to Switzerland Amid Privacy Concerns (октябрь 2024).
• Human Rights Watch — Disrupted, Throttled, and Blocked: State Censorship, Control, and Increasing Isolation of Internet Users in Russia (2025).

Связанные посты в этом блоге

• Цифровое наследство: «Вот и всё, что останется после меня» — мессенджеры после смерти владельца.
• Эпоха недоверия — почему мы переписываем всё под себя.