Как я решил проблему «третьей стороны» в мессенджерах, или почему сервер - это слабое звено

Помните обещания об «абсолютной приватности»? Марк клялся, Павел обещал, но в 2025-м новости о мессенджерах всё больше напоминали сводки с фронта: утечки сотен гигабайт переписки, найденные бэкдоры и данные, внезапно ставшие доступными «третьим лицам».

Пока большинство проектов пытается защитить серверную часть или внедрить еще более сложные протоколы шифрования, я решил пойти другим путем: просто убрать сервер из этой цепочки.

От теории к практике

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

Я реализовал эту концепцию как технический эксперимент, чтобы проверить её на прочность. Оказалось, что схема вполне жизнеспособна. То, что начиналось как проект «на коленке», превратилось во вполне рабочий инструмент, где безопасность гарантирована не обещаниями разработчика, а самой архитектурой системы.

В чем реальная уязвимость сигнальных серверов

Многие мессенджеры гордятся стойкостью шифрования - AES-ключи, обфускация трафика и борьба с DPI выглядят солидно. Но остается один критический нюанс: у них всё равно есть сервер.

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

Ну и наконец в серверную могут просто прийти уполномоченные люди которые потребуют предоставить доступ ко всему :-).

Концепция чистого P2P

В Silent Channel я исходил из того, что лучшая защита - это отсутствие объекта для атаки. Здесь нет серверов. Вообще. Даже для того, чтобы ваши устройства «увидели» друг друга.

В классических мессенджерах вы подключаетесь к центральному узлу, который фиксирует ваш IP, время входа и личность собеседника. В моем приложении вы генерируете файл запроса (Offer), передаете его собеседнику любым удобным способом (через почту, другой мессенджер или физически на флешке), получаете файл ответа (Answer) - и только после этого устанавливается прямой туннель. В итоге для остального интернета вашего общения просто не существует.

Цена приватности

Соединение нужно устанавливать заново для каждой сессии, вручную обмениваясь данными.

Тут есть важный технический момент: почему эти файлы нужно использовать быстро? Успех P2P-соединения зависит от того, найдут ли устройства друг друга в сети. Файлы содержат ICE-кандидаты - список ваших текущих IP-адресов и портов на данный момент.

Соединение достаточно сильно зависит от стабильности сети:

  • При смене IP (переход с Wi-Fi на мобильную сеть) старые данные в файле моментально становятся недействительными.

  • В отсутствие сервера, который обновлял бы маршруты в реальном времени, вы полагаетесь на «снимок» сети. Если условия изменились за время передачи файла, туннель не построится.

  • При слабой связи бывает не сразу удается установить соединение, приходится повторять процесс подключения.

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

Автономность и отказ от сервисов Google

Я старался сделать приложение максимально независимым:

  • Здесь нет аккаунтов. Никаких привязок к номеру телефона или почте. Нет записи в базе - нет данных, которые можно сопоставить с личностью.

  • Никакого Firebase или Google Play Services. В приложении нет облачных уведомлений и встроенной аналитики, что кстати делает его удобным для любых кастомных сборок Андроид.

  • Никакой рекламы и скрытых метрик. Передавать данные просто некуда - в коде не заложены адреса серверов для сбора статистики.

Почему это критично сейчас

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

В централизованных системах администратор сервера знает о вас всё, кроме смысла слов, но смысла часто и не требуется для деанонимизации. В моем приложении нет даже «Личного кабинета» - это было бы абсурдом в контексте приватности. Только код и прямое соединение.

Стек технологий и платформы

Для тех, кому интересна техническая часть:

  • WebRTC в чистом, без-серверном виде.

  • Serverless Signaling - отсутствие посредников при обмене SDP-пакетами.

  • KMP (Kotlin Multiplatform) - основа проекта. Благодаря этому стеку приложение уже сейчас доступно не только на Android, но и в виде полноценной Desktop-версии (Windows). Оба клиента работают по идентичной логике безопасности. На данный момент это две основные платформы, для которых возможна сборка и стабильная работа P2P-протокола.

Интересный технический парадокс: установить и поддерживать стабильное соединение для текстового чата в чистом P2P зачастую сложнее, чем для видео или аудио. Это связано с фундаментальными различиями в передаче потоковых и дискретных данных через WebRTC.

Для передачи голоса и видео используется протокол SRTP на базе UDP. Это концепция «живого потока», где потеря части пакетов не критична: мы просто их игнорируем, так как следующий пакет придет через миллисекунды. Текстовая же переписка работает через Data Channel (протокол SCTP поверх UDP), который обязан гарантировать доставку каждого байта в правильной последовательности.

Здесь и кроется главная проблема «молчаливого» канала. Видеопоток - это непрерывная бомбардировка сети пакетами, которая удерживает NAT-сессию роутера открытой. Чат же может «молчать» минутами, и в отсутствие серве��а, который мог бы пропинговать клиента, домашние роутеры быстро закрывают порты, считая соединение неактивным. В итоге туннель схлопывается именно в моменты тишины.

Кроме того, Data Channel требует жесткого контроля состояния. Если из-за кратковременной смены сети потеряется служебный пакет подтверждения, канал может уйти в ошибку и потребовать пере-подсоединения. Видео в такой ситуации просто «дернется» и продолжит трансляцию.

Именно поэтому аудио- и видеозвонки субъективно кажутся стабильнее. При их выборе приложение задействует механизмы, которые на уровне системы имеют приоритет. Постоянная передача трафика не дает сетевому оборудованию «забыть» маршрут. Это предотвращает агрессивное закрытие процесса системой ради экономии энергии.

В итоге мы получаем техническую иронию: передать «тяжелое» видео в мире без серверов иногда проще, чем установить текстовое общение. Зачастую установить одно только соединение для чата (Data Channel) не получается за один подход, когда аудио или видео устанавливается без проблем.

О доверии

Я предвижу главный вопрос сообщества: «Если приложение про приватность, почему код не открыт?». Хочу ответить на это максимально честно.

Silent Channel — это мой коммерческий проект, в который вложено много сил на решение задач P2P‑стабильности. На данном этапе я выбрал модель закрытого кода для защиты интеллектуальной собственности и монетизации. Однако приватность здесь базируется не на «честном слове», а на физических ограничениях архитектуры:

  • Проверка сетевой активности. Любой задавшийся целью может запустить сниффер (Wireshark, PCAPDroid) и убедиться: приложение не инициирует соединений с внешними серверами. В коде просто нет адресов, куда могли бы уходить логи или метаданные.

  • Нету бигтеха. Писал чуть выше - в приложении полностью отсутствуют Firebase, Google Play Services и любая другая аналитика. Нет рекламы. Это можно проверить через анализ манифеста. Так что в случае креша мне сложнее его поймать, так что очень жду живые отзывы.

  • Несохранение данных. Ваша переписка не сохраняется ни на каких серверах (их просто нет) и не кэшируется в постоянную память устройства. Все данные существуют только в рамках текущей сессии исключительно в оперативной памяти.
    - Важное уточнение: Принятые файлы сохраняются в указанном вами месте (по умолчанию в папке «Загрузки»).

  • Минимум разрешений. Silent Channel запрашивает абсолютный минимум системных разрешений. Ему не нужны ваши контакты, доступ к SMS или геолокации. Только аудио, видео звонки - собственно для этого он и нужен ).
    Вы можете убедиться посмотрев файл манифеста приложения по ссылке или самостоятельно дастать его из файла апк.

Для поддержки проекта существуют две версии приложения. Цена платной версии в Google Play зависит от страны, она снимает все лимиты на общение. Рассматриваю вариант оплаты другими методами.

Бесплатная версия полнофункциональна в плане безопасности, но имеет следующие технические ограничения: Длительность аудиозвонка - до 3 минут, видеозвонка - до 1 минуты, максимальный размер пересылаемого файла в чате - до 3 МБ.

Я понимаю, что для многих отсутствие Open Source - это «красный флаг». Но в данном случае архитектура Clean P2P делает наличие бэкдора практически бессмысленным: ему просто некуда отправлять украденные данные, так как в системе отсутствует центральный узел сбора.

В общем я открыт к диалогу.

Итог

Пока индустрия спорит о том, чей сервер защищеннее, я предлагаю просто выйти из этой системы координат. Если вы не хотите, чтобы ваши данные попали в сеть - не отправляйте их туда.

Silent Channel - это эксперимент по возвращению контроля над общением самому пользователю. Это не так удобно, как обычный чат, но это цена за то, что ваше общение остается только вашим.

��уду рад любому фидбеку. Сразу отмечу: при анализе предложений я в первую очередь смотрю на то, как идея влияет на максимальную безопасность и анонимность пользователя, и только во вторую - насколько это повышает удобство интерфейса.

Больше деталей

Для генерации картинок и в качестве шеф редактора использовался AI.