Оболочка для МАХ по типу как Norton Commander с шифрованием

Вопрос возможно нубский, так что заранее извиняюсь.
Возможно ли технически создать оболочку для МАХ по типу как Norton Commander для Ms-Dos (мне просто никакой другой пример в голову не приходит), чтобы пользователь только с помощью нее взаимодействовал с МАХ и она сама обменивалась ключами и шифровала весь траффик? Да инфа будет храниться на их сервере, но в виде абракадабры.
И пожалуйста не пишите камменты что МАХ вообще ставить зашквар и т.д. и т.п. я и так все это знаю.

Да, пишите поддержку протокола Max для Pidgin или Miranda NG. Они позволяют поверх любого поддерживаемого протокола навернуть GPG или OTR.

Осложняется это тем, что протокол Max проприетарный, спецификаций в открытом доступе нет. Поэтому мы в Миранде своими силами его реализовывать не собирамся, у нас нет на это человеческих ресурсов.

Хех, там всё просто. Я за 5 минут смог “протокол” для него написать.

Там обычный WebSocket over TLS.

Открывается соединение:
Клиент шлет браузерные данные (хоть хардкодом).
Сервер шлет какую-то фигню.
Клиент шлет токен (из браузера).

Дальше в браузере обычно происходит синхронизация чатов (через тот же websocket канал). Но мы её делать не будем.

ВСЁ, теперь можно слать сообщения в plaintext. Но перед этим желательно отправить “Typing” ивент.
Принимаются сообщения от любых пользователей также в plaintext.

Каждые 30 секунд слать какую-то фигню в качестве “Heart beat” или “keepalive”.

Они даже и не пытались ничего шифровать/обфусцировать. Тут протокол легче чем Telegram раза в 5, никакой криптографии и сложных состояний. Игрушечная реализация, можно сказать.


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

В общем, оказалось, что всё уже украдено до нас, пользуйтесь

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

Ещё есть пример[1] и пример[2] Python-обёрток над внутренним API.

Я так понимаю, всё-таки хотелось бы IPC оболочку возможность именно создать, а не клиент.

О, значит не меня одного такие мысли посещали! Однако, мне кажется оболочка будет более перспективной, если конечно возможна ее реализация, т.к. будет непалевной.

Будут банить как на воцапе.
Блокировать аккаунт
Сечется это довольно просто.
Выпускается новая официалка клиента, требуется принудительное обновление.
Новый клиент шлет какую-то новую сигнатуру, опенсорс не поспевает за “бомбами”

Они даже и не пытались ничего шифровать/обфусцировать. Тут протокол легче чем Telegram раза в 5, никакой криптографии и сложных состояний. Игрушечная реализация, можно сказать.

Это типовая реализация IM. Вся криптография в TLS в виду отсутствия E2EE.
Сложность протокола TG на мой взгляд это такой неявный vendor lock (на ихний tdlib).

Будут банить как на воцапе.
Блокировать аккаунт

Это идет несколько в разрез с планами пересадить население на национальный IM.
В обсуждении клиента Komet на 4pda возможность спровоцировать бан аккаунта даже рассматривали как фичу. :wink:

Я уже слышал банят акки за то, что название не совпадает с паспортом. Например бизнесс акк салон красоты “такой то”… Вместо ФИО

Да, будут палки в колеса вставлять, взлом/обман – не выход. Решение, если нужен только E2EE, – использовать “App Extension” (расширение приложения) – кастомную клавиатуру.

Цитирую предназначение:

A custom keyboard replaces the system keyboard for users who want capabilities such as <…> the ability to enter text in a language not otherwise supported.

Юридически всё чисто, используем язык криптографии, а не человеческий.

Примеры реализаций:

  1. AirLock
  2. PGP Everywhere
  3. Cipherboard

Текст вводится прямо в поле ввода клавиатуры, а не мессенджера, чтобы не перехватили ввод.
Расшифровывается помещением в буфер обмена → клавиатуру или “Share”.

Либо, а лучше, разработать собственную.

Альтернативно, можно настроить Shortcuts Automation API для (раз)шифровки текста через скрипты по SSH или JS в Safari, либо кодирование в Base64 или реализация шифра Цезаря для защиты от простого парсинга (без криптографической устойчивости).

Зачем клавиатуру, оно что файлы пересылать не умеет?

На смартфоне не получится нормально чатиться в реальном времени через файлы. То есть их создавать где-то, как-то, потом пересылать… Хотя можно по идее через “Share” функцию из какого-то приложения, которое эти файлы будет формировать. Но потом ведь собеседник тоже их слать будет, ну и их в целом можно через “Share” в другое свое приложение для расшифровки пересылать.

Ну это туда сюда мотаться так, такое себе..

А это - какой никакой компромисс по UX.