На сьогоднішній день мобільні месенджери є одними з найбільш популярних програм для смартфонів, випереджуючи навіть соціальні мережі. Не вщухають суперечки щодо того, який месенджер найкращий, найправильнійший та найбезпечніший. Втім, є деякі проблеми, які дозволяють прогнозувати радикальні зміни у моделі їх функціонування. Попит з боку користувачів на ці зміни є, і досить значний.

У чому проблема?
Найперше – це відсутність єдиного стандарту з’єднання. Ви не можете, подібно до листування по e-mail, написати у Скайпі користувачеві Вайбера. Для того, щоб спілкуватися з людьми за допомогою сучасних месенджерів, вам доведеться встановити їх цілу купу. Необхідність витрачати час на освоєння нового інтерфейсу, втрачена у потоці пуш-повідомлень інформація – це далеко не повний перелік претензій користувачів до екосистеми миттєвих повідомлень.
Найбільш часті:
– Централізована архітектура
– Закритий протокол
– Прив’язка до номера телефону
– Відсутнє end-to-end шифрування
– Необхідність бути зареєстрованим в супутньому сервісі
Дуже багато зауважень у користувачів з приводу можливості викриття їх переписки, але насправді це неоднозначно – повністю «безпечний» у цьому плані месенджер може перетворитися на розсадник шахрайства та злочинів проти особистості.
Перелік вимог до ідеального месенджера з боку «просунутого» користувача виглядає приблизно таким чином:
1. Відкритість та розробка в інтересах суспільства.
Ніяка компанія не повинна мати монопольну можливість управління всією архітектурою і розробкою. Розробка повинна вестися шляхом колективних обговорень, подібної до тої, як затверджуються RFC. Ліцензії не повинні будь-яким чином обмежувати використання протоколу. Це не виключає існування комерційних клієнтів, подібно до того, як зараз існують платні Email-клієнти і компанії, які заробляють на технологіях електронної пошти.
2. Децентралізованість
Тут мається н увазі не виключно peer2peer, при якому відсутні взагалі будь-які сервери. Опорні сервери можуть існувати, подібно до супернодів Skype, наприклад для передачі важкої медіаінформації, кешування, обміну даними про маршрутизації і т.д. Чистий P2P в багатьох випадках незручний, наприклад для мобільних користувачів з вузьким нестабільним каналом. Це може бути децентралізація, подібна Email і Jabber, коли існує велика кількість незалежних серверів, які можуть спілкуватися між собою. Закриття одного або декількох серверів не вплине на систему. Навіть якщо цілі країни або континенти будуть відрізані від інтернету, система продовжить працювати. Ймовірно, потрібно передбачити і роботу в разі недоступності сервера. Тобто, клієнт, при бажанні, може делегувати зберігання облікових записів сервера, і входити за логіном-паролем, або зберігати приватні ключі локально і входити в мережу самостійно без сервера. Таким чином можна зберегти зручність для простих користувачів і дати можливість кваліфікованим користувачам забезпечити достатній рівень безпеки.
3. Захищеність від блокувань
Протокол повинен бути стійкий до спроб блокування, вміти переключатися між різними портами, транспортними протоколами і диверсифікувати трафік таким чином, щоб його не можна було виділити системами DPI. У самому крайньому випадку, використовувати в якості транспорту будь-який з доступних протоколів, наприклад HTTPS. Навіть якщо всі можливі точки входу будуть повністю закриті на маршрутизаторах провайдера, повинна існувати можливість вказати власну адресу шлюзу, подібно до того як це зроблено в Tor.
4. Захищений від прослуховування
Всі комунікації між кінцевими користувачами не повинні передаватися і зберігатися у відкритому вигляді ніде, крім пристроїв користувача. Для зручності синхронізації між пристроями користувача, історія може зберігатися на сервері при його бажанні, але повинна бути зашифрована. Наприклад, майстер-паролем, як це зроблено в ProtonMail. При цьому повинні бути зручні інструменти для верифікації ключів, використовуваних для end-to-end шифрування, подібно до того як це зроблено в RedPhone. Програма-клієнт повинна в обов’язковому порядку повідомляти користувача про ненадійне з’єднання, спроби перехоплення або проблеми з шифруванням.
5. Інтероперабельність
Все реалізації клієнтів повинні бути сумісні на базовому рівні, описаному в стандарті. Тобто дзвінки і чат повинні працювати між усіма існуючими програмами, щоб мати можливість дзвонити зі Skype в Viber і навпаки. Фірмові нестандартні функції можуть бути доступні між клієнтами одного виробника.
Прочитати міркування фахівця з цього приводу можна за посиланням: https://habrahabr.ru/