В MAX нередко пытаются найти отдельный режим вроде «секретных чатов» или явную настройку сквозного шифрования. В публичных материалах сервиса такие режимы не описаны, а в интерфейсе нет очевидной маркировки, которая обычно сопровождает E2EE (проверка ключей, отдельный тип диалога и т.п.). Это не доказывает, что E2EE нигде не используется, но как минимум оно не заявлено как базовая гарантия сервиса.
В юридических документах MAX нет заявлений о сквозном шифровании. Зато есть формулировки про автоматическое сканирование сообщений и передачу данных по законному запросу. В сумме это плохо сочетается со строгой моделью E2EE «по умолчанию», поэтому разумнее исходить из того, что сервис технически способен обрабатывать содержимое сообщений на своей стороне хотя бы в отдельных точках тракта (например, в рамках антиспама и фильтрации).
Что обещает MAX и что следует из документов
Начать стоит с терминологии. На ней проще всего запутать пользователя, потому что под одним словом «шифрование» часто скрывают разные уровни защиты.
«Encrypted in transit» (шифрование при передаче) означает, что трафик между приложением и сервером идет по защищенному каналу, как правило TLS. Это базовая гигиена: без нее любой современный мессенджер выглядел бы странно.
Сквозное шифрование (E2EE) устроено иначе. Сообщение шифруется на устройстве отправителя и расшифровывается только у получателя. Сервер в идеальной модели видит только зашифрованные данные и метаданные доставки. При такой схеме оператор сервиса не может прочитать переписку, потому что ключей у него нет.
Что пишут в документах MAX? В пользовательском соглашении прямо указано, что сотрудники компании не осуществляют мониторинг сообщений пользователей, но компания может использовать автоматические системы и фильтры для сканирования сообщений с целью ограничения рассылки спама или иного нежелательного или незаконного контента. Такая оговорка характерна для модели, где у сервиса есть техническая возможность анализировать содержимое сообщений в рамках автоматической обработки. Документ: пользовательское соглашение.
В политике конфиденциальности описаны сценарии передачи данных, включая передачу информации исполнительным и судебным органам по законному требованию. Там же указано, что трансграничная передача персональных данных пользователей не осуществляется (это формулировка о трансграничной передаче, а не отдельное доказательство «чтения переписки»). Ссылка: политика конфиденциальности.
В карточке приложения в Google Play в разделе Data safety отмечено: «Data is encrypted in transit». Это означает защиту данных при передаче между устройством и серверами сервиса и само по себе не является заявлением о сквозном шифровании. Важно помнить, что Data safety заполняется разработчиком и описывает практики обращения с данными, но не заменяет техническое описание криптопротокола. Страница в Google Play.
Почему архитектура MAX плохо совместима со сквозным шифрованием
MAX выглядит скорее как платформа, чем как минималистичный мессенджер: веб-версия, мультиустройство, боты, мини-приложения, интеграции, каналы, сервисы вокруг цифрового ID. Это удобно, но именно такие возможности обычно усложняют E2EE «по умолчанию»: приходится решать задачи управления ключами, синхронизации между устройствами и совместимости с серверными функциями.
Хороший пример - боты. Документация API предполагает, что серверная часть платформы принимает HTTPS-запросы, получает события, позволяет отправлять сообщения, редактировать и удалять их. В E2EE-модели такие сценарии обычно возможны только в ограниченном режиме и с явным пониманием пользователя, что переписка с ботом не равна приватному E2EE-диалогу. Если же значимая часть функциональности строится вокруг серверной логики сообщений, сквозное шифрование по умолчанию становится менее вероятным. Документация: API MAX.
Еще один признак - фильтрация и антиспам. В соглашении MAX допускается автоматическое сканирование сообщений для антиспама и борьбы с незаконным контентом. При строгом E2EE это обычно решают иначе: либо за счет клиентских проверок, либо через анализ метаданных и поведенческих сигналов, либо через разные режимы чатов. В случае MAX по формулировкам документов логичнее предполагать классическую серверную антиспам-обработку, где у сервиса есть техническая возможность видеть содержимое на этапе проверки.
Что насчет звонков? В большинстве VoIP-систем голос и видео шифруются как минимум на транспортном уровне. Но это не тождественно E2EE: многое зависит от того, где завершается криптоконтур и как устроена маршрутизация медиапотока. По публичным документам MAX сделать строгий вывод о сквозном шифровании звонков нельзя, поэтому корректнее фиксировать лишь общий принцип и неопределенность по реализации.
Практическая проверка. В E2EE-мессенджерах обычно есть механизмы верификации ключей (safety number, QR-код для сверки), отдельный режим «секретного чата» или явная маркировка защищенного диалога. В публичном FAQ MAX раздел «Безопасность» посвящен в основном приватности профиля, безопасному режиму, фильтрам контента и управлению доступами. Упоминаний про верификацию ключей или аналогичные механизмы там нет. Раздел безопасности в FAQ.
Сравнение типичных реализаций
| Сценарий | Если E2EE нет (обычный серверный мессенджер) | Если E2EE есть (сквозное шифрование) |
|---|---|---|
| Что видит сервер | Содержимое сообщений в расшифрованном виде (плюс метаданные доставки) | Только зашифрованные данные и метаданные доставки, без ключей расшифровки |
| Шифрование «по дороге» | Есть: TLS между приложением и сервером | Есть: TLS тоже используется, но поверх него работает E2EE |
| Антиспам и фильтрация по тексту | Сервер может анализировать содержимое сообщений и вложений | Сервер не может читать текст, поэтому фильтрация либо по метаданным, либо на стороне клиента, либо через отдельные чаты без E2EE |
| Боты и мини-приложения | Сервер передает ботам содержимое сообщений через API, бот может отвечать «по тексту» | Обычно E2EE не применяется к чатам с ботами, либо используется отдельный режим, где пользователь явно понимает, что переписка не E2EE |
| Восстановление переписки и мультиустройство | Проще: сервер хранит историю и синхронизирует устройства | Сложнее: нужно переносить и защищать ключи между устройствами, история на сервере хранится в зашифрованном виде или не хранится вовсе |
| Проверка «того самого собеседника» | Обычно нет верификации ключей | Обычно есть механизмы проверки ключей (QR-код, числовой код, safety number) |
Что из этого следует на практике
Главный вывод. Если вам нужна криптографическая гарантия «оператор не может прочитать», по публичным документам MAX не выглядит продуктом со сквозным шифрованием по умолчанию. Формулировки про автоматическое сканирование и общая логика платформенных функций больше указывают на централизованную модель, где защита строится вокруг контроля аккаунта, приватности профиля и шифрования транспорта.
Более практичный вывод. Это не делает MAX «плохим» автоматически. Для уведомлений, организационных чатов, сервисных сценариев и бытовых коммуникаций серверная модель часто приемлема. В таких случаях основные риски обычно связаны с угоном аккаунта, фишингом, подменой устройства, социальной инженерией и настройками приватности.
Про сегментацию. Разумный подход - разделять каналы общения. MAX можно оставить под сервисные и организационные сценарии и те контакты, где вы допускаете раскрытие переписки по установленной процедуре. Для чувствительных разговоров лучше использовать мессенджеры, где E2EE является проверяемой частью модели безопасности и сопровождается понятными механизмами верификации.
