Мессенджер с открытым исходным кодом для андроид

Опубликованы исходники швейцарского криптомессенджера Threema

Архитектура веб-клиента Threema, источник

Защищённый мессенджер Threema открыл исходный код и инструкции по воспроизводимой сборке приложений. Опубликованы 12 репозиториев для клиентов Android, iOS, веб-версии, рилеев нотификаций и других компонентов. Это важнейшее событие в истории компании Threema GmbH, которая с публикацией исходников выходит на новый уровень разработки.

На фоне массового исхода пользователей WhatsApp платный мессенджер Threema стал одним из самых скачиваемых приложений в мире, вместе с Telegram, Signal и Element (децентрализованная сеть Matrix), см. также статью «Какое шифрование лучше: Signal или Telegram?».

Threema наименее известна в этой плеяде. Зато у неё есть одно преимущество перед конкурентами — швейцарская юрисдикция.

Threema — сервис для обмена сообщениями, который реализует сквозное шифрование коммуникаций (E2EE). Поддерживаются аудио- и видеозвонки, обмен файлами и другие возможности современных мессенджеров.

Есть версии для Android, iOS и веба. Отдельного десктопного приложения, в том числе под Linux, пока не разработано.

Интересно, что исходники на Github обновляются только с обновлением клиентов, то есть один коммит = один релиз. Пул-реквесты и баги в репозиториях Github не принимаются, только по почте.

Юрисдикция — это важно

Threema развивается швейцарской компанией Threema GmbH. Серверы проекта тоже в Швейцарии. Именно швейцарская юрисдикция — главное преимущество Threema перед Signal (США) и Telegram (США, Великобритания, разработка переезжает по офисам в разных странах, сейчас находится в ОАЭ, основатели и программисты преимущественно из России, инвесторы из России и других стран, кроме США).

Юрисдикция управляющей компании — вовсе не второстепенный вопрос, когда у властей возникают претензии к отдельным пользователям, клиентам сервиса. Например, в США действуют законы, по которым компания обязана секретно внедрить бэкдоры в свои продукты и сервисы и реализовать слежку за пользователями, если секретный суд примет такое решение.

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

Многие помнят историю почтового сервиса Tutanota, которого немецкий суд заставил установить бэкдор для расшифровки почты определённого пользователя. Владельцы ганноверской компании тогда жалели, что не выбрали иную юрисдикцию. В одном из интервью они сказали, что рассматривают переезд в Швейцарию, хотя правовая ситуация в Германии не такая плачевная: «Правовая ситуация и конституция Германии в основном очень хорошие и защищают конфиденциальность людей. Общественная активность также помогает нам предотвратить или ослабить проблемные законы (слежку)».

В США правовая ситуация гораздо хуже, особенно после 9/11. В августе 2013 года был вынужден закрыться почтовый сервис Lavabit. Основатель и владелец сервиса Ладар Левисон (Ladar Levison) сказал, что принял это решение после долгих раздумий:

«Я бы хотел иметь легальную возможность рассказать вам о всех событиях, которые привели к такому моему решению, но я не могу. Я чувствую, что вы заслуживаете знать, что происходит. Первая поправка должна гарантировать мне свободу слова в ситуациях вроде этой. К сожалению, Конгресс принял законы, которые говорят обратное. На данном этапе я не могу поделиться событиями последних шести недель, хотя я дважды отправлял соответствующие запросы [чтобы мне разрешили это сделать]», — написал основатель Lavabit Ладар Левисон. Он не вдаётся в подробности своего дела, но обращается ко всем пользователям: «Минувшие события преподали мне один очень важный урок: до решения Конгресса или чёткого судебного прецедента я _очень_ не рекомендую кому-либо доверять персональные данные компании, которая физически привязана к США».

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

В такой ситуации вопрос юрисдикции конкретного веб-сервиса становится ключевым. В мире осталось не так много мест, где права человека ценятся выше, чем права государства.

Threema GmbH — швейцарский стартап, который получил финансирование от немецко-швейцарской инвестиционной компании Afinum Management AG. Основатели компании — три программиста Мануэль Каспер (Manuel Kasper), Сильван Энгелер (Silvan Engeler) и Мартин Блаттер (Martin Blatter).

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

Разработчики обещают выпустить полноценный десктопный клиент, в том числе под Linux, которым можно будет пользоваться без смартфона: «Безопасность и защита приватности глубоко укоренились в ДНК Threema, поэтому наш код регулярно проходил внешний аудит (см. результаты аудита за ноябрь 2020 года). Благодаря открытым исходникам любой желающий может самостоятельно проверить безопасность Threema и убедиться, что опубликованный исходный код соответствует загруженному приложению. В будущем благодаря инновационному решению с несколькими устройствами можно будет использовать несколько устройств параллельно. В отличие от других подходов, на сервере не останется никаких следов персональных данных. Благодаря этой технологии Threema можно использовать на ПК без смартфона. В итоге, Threema станет ещё более надёжным и ещё более удобным приложением».

В отличие от Telegram, серверы Threema не хранят сообщения и файлы пользователей, поэтому здесь расходы на инфраструктуру минимальны.

Источник

Подборка мессенджеров с открытым исходным кодом

ADMIN

Мессенджеры, которые уважают вашу конфиденциальность.

) — возможно, самый безопасный децентрализованный сервис, который работает через Tor-сеть, чем значительно повышает анонимность конечного получателя сообщений.

) — чат-клиент с открытым исходным кодом, ориентированный на обеспечение чистой и надежной работы с Jabber/XMPP с учетом вашей конфиденциальности.

) — одноранговая (P2P) система обмена сообщениями, основанная на высоконадежной аппаратной архитектуре для защиты пользователей от пассивного сбора, атак MITM и, что наиболее важно, удаленной кражи ключей.

) — это платформа с открытым исходным кодом, разработанная на JavaScript для организации чатов и осуществления VoIP звонков с защитой данных.

) — p2p приложение для обмена мгновенными сообщениями с открытым исходным кодом.

) — децентрализованный клиент мгновенного обмена сообщениями, основанный на XMPP.

) — защищенный одноранговый мессенджер, который работает с доступом к Интернету или без него.

) — клиент Tox для Andriod.

) — интересный и простой проект, реализующий анонимный и одноранговый мессенджер.

) — это безопасное приложение для обмена сообщениями, крипто-кошелек и децентрализованный Web3-браузер.

) — децентрализованный мессенджер, использующий сквозное шифрование во всех чатах с применением криптографического протокола TLS 1.3. Может подключаться к стандартному SIP аккаунту, а может и в p2p режиме.

) — децентрализованный кроссплатформенный мессенджер со сквозным шифрованием, связь осуществляется через протоколы электронной почты (протокол Autocrypt).

Источник

Пишем мессенджер с открытым исходным кодом

Давным-давно в одной далекой стране была компания America Online. И был у нее удивительный частный Интернет за заборчиком, где вместо URL-ов были «keywords»: что-то среднее между адресом веб страницы и купленным ключевым словом в рекламе. Компании боролись за интересные ключевые слова, как сейчас борются за домены, а реклама выглядела так: «посетите нас во всемирной сети по адресу www.example.com, или наберите AOL Keyword: ‘banking'».

История имеет свойство повторяться. Сейчас роль Америки Онлайн играют основные мессенджеры: все они за заборчиками, несовместимы друг с другом, все изобретают свои keywords, желают схватить пользователя и уже никогда не отпускать. Компании не заинтересованы в открытости: более крупные игроки не желают делиться пользователями с более мелкими и уж тем более становиться открытыми. В результате невозможно послать сообщение даже из WhatsApp в Facebook Messenger, несмотря на то, что оба принадлежат одной компании. Да и пользователи ценят надежность и удобство выше абстрактной открытости, хотя многих раздражает, что часть друзей, например, в Telegram, часть в WhatsApp, а родители в Skype.

А вот роль открытого интернета, к сожалению, сегодня не играет никто. Ситуацию хочется изменить. Если XMPP не справился, может быть кто-то другой сможет? И тут рассказ про Tinode.

Что такое Tinode

Tinode — мессенджер с полностью открытым исходным кодом на Github. Все клиентские приложения (ReactJS и Андроид) лицензированы под Apache 2.0, для того, чтобы упростить создание коммерческих приложений на основе Tinode, сервер под GPL 3.0. Цель проекта — создать федерированный мессенджер, который прост и удобен как для пользователей, так и для операторов. Поставил — и все работает, как MySQL или Nginx. В долгосрочной перспективе цель проекта – создать открытую альтернативу существующим проприетарным мессенджерам, повторить в отношении мессенджеров то, что сделал Android в отношении операционных систем для мобильных телефонов.

Что он умеет

Поддержка множественных устройств.

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

Очевидно, что хранение информации пользователя на сервере подходит не всем, так как создает риски нежелательного доступа: чем больше копий данных хранится в разных местах, тем выше вероятность, что что-то пойдет не так. Для этого предусмотрена возможность эфемерных сообщений и сообщений, которые удаляются с сервера после доставки клиенту. Технически, существует и возможность не хранить контакты на сервере постоянно — клиент отправляет их на сервер в момент подключения (login), затем они удаляются после logout. Однако, авторы посчитали это непрактично сложным и не стали делать.

Онлайн статус

Трансляция онлайн/оффлайн статуса пользователя в мессенджерах воспринимается как что-то само собой разумеющееся, однако, это весьма тяжелая в реализации фича. Нужно, чтобы она «просто работала», предсказуемо и надежно. Надежность работы исключила генерацию статуса на клиенте, как это реализовано в некоторых XMPP приложениях. В случае Tinode, сервер генерирует онлайн статус и рассылает по адресной книге, что, опять же, требует хранения контактов на сервере и их синхронизацию с клиентскими приложениями.

Простота протокола

Протокол хотелось сделать таким, чтобы кривая обучаемости была пологой – не нужно знать всего, чтобы начать. Спецификация получилась очень компактной: 10 запросов клиента, 5 ответов сервера. Например, по сравнению с 200+ страницами только core XMPP, не считая extensions, это почти записка на салфетке.

Представление данных отделено от сетевого протокола. Протокол лишь требует определенную структуру данных, но не требует, чтобы они передавались по сети каким-то определенным образом. Сейчас сервер поддерживает JSON по websocket и long polling, c TLS и без, плюс gRPC по TCP. Поддержка gRPC была реализована одним разработчиком за две недели, включая написание текстового клиента на Питоне. Добавление поддержки иных форматов данных и протоколов, например, MessagePack или Noise, вряд ли займет намного больше.

Расширяемость

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

Было принято решение разделить функционал на три части — основной, сетевой и вспомогательный. Основной — это то, что позволяет Tinode выполнять основную функцию — пересылать сообщения. Сетевой — функционал взаимодействия в серверами, как формат передаваемых данных и сетевой протокол. Вспомогательный — то, что решает чью-то локальную задачу, например, поддержка конкретной базы данных в качестве бэкенда или какой-то метод авторизации, но никак не влияет на другие сервера или пользовательские приложения. Основной функционал реализован в основном коде. Сетевой функционал выделен, но также хранится в основном репозитории для того, чтобы по возможности избежать создания несовместимых серверов. Вспомогательный реализован в виде плагинов — компилируемых Go интерфейсов (поддержка разных баз данных, разных авторизаторов, пуш нотификации, валидаторы по емейл или телефону, поддержка каптчи и т.п.) и gRPC endpoints (чатбот и поисковый интерфейс).

Прочее

Почему Go?

Сервер для мессенджера по сути роутер: получает сообщение из одного канала, как-то его обрабатывает, затем передает в другой канал или каналы. Go (как и Erlang, но это уже другая история) идеально подходит для создания такого функционала т.к. содержит примитивы goroutine и chan, делающие организацию потоков и обмен данными между ними эффективным и простым.

Безусловно, роутер можно написать и на C/C++, и на Java. Однако, при прочих равных, код скорее всего получится более сложным и потребует больших усилий для избежания дедлоков.

А что потом?

Федерация

Одна из основных задач для Tinode на ближайший год — создание платформы для федерации. Так, чтобы любой желающий мог запустить свой Tinode сервер, который бы мог обмениваться сообщениями с любым другим сервером, точно так, как это возможно с емейлом. Уже сейчас возможна кластеризация серверов. Сетевой обмен между сервером и клиентами идет по TLS websocket, что для внешного наблюдателя мало отличимо от простого HTTPS трафика.

Публичный DNS, вероятно, будет использоваться, по крайней мере первоначально. Однако, в будущем поиск чат-серверов будет осуществляться также, как это сделано в Bittorrent — при помощи DHT, распределенной хеш таблицы.

Хочется также избежать и проблем, за которые часто критикуют XMPP. Например, XMPP сервера очень разговорчивы. До половины сообщений является дублирующими, когда XMPP-клиент рассылает онлайн уведомления индивидуально каждому контакту из адресной книги.

Репутация и распределенное принятие решений

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

• Криптографическая идентификация сервера-отправителя.
  Изначально, SMTP вообще не предполагал какой-либо идентификации отправителя. Не стоит снова наступать на эти грабли. Каждый сервер, желающий установить контакт, будет представлен криптографическим сертификатом. «Ну да», скажете вы, «я сейчас нагенерю 100500 сертификатов и каждый раз буду представляться новым чистым сервером». И будете правы. Поэтому следующий пункт.
• Распределенный учет репутации.
  Когда к нам стучится новый, неизвестный сервер-отправитель, мы сделаем запрос к известным серверам с просьбой сообщить рейтинг нового сервера. И в зависимости от ответа установим, например, скорость, с которой новый сервер может посылать нам сообщения.

Если посмотреть на распределенную систему принятия решения и учета репутации с высоты птичьего полета, то станет заметно сходство с blockchain. Возможно, blockchain (но не криптовалюта) может быть использован в качестве основы для построения распределенной системы репутации, хотя пока и не очевидно каким образом.

Шифрование

Ну а как же в наши дни без шифрования сообщений? Чаты между двумя людьми, вероятно, будут шифроваться OTR. С групповыми чатами пока непонятно. Все известные схемы шифрования групповых чатов либо имеют значительный недостатки, либо тяжеловесны и сложны в реализации. Также, не очевидно, насколько важно шифрование групповых чатов: «Если тайну знают двое – это уже не тайна, а если трое – это уже базар.»

Источник