Да, если считать клиентский код доверенным и неизменённым, описанный MITM не получится: handshake аутентифицируется секретом из URL fragment, которого relay-сервер не получает.
Но более общий тезис - верный: поскольку сам 410.chat раздаёт JS, скомпрометированный сервер может отдать изменённый клиент, который уже украдёт secret или plaintext. HTTPS в таком случае не спасает — он лишь подтверждает, что изменённый код действительно пришёл от 410.chat. Это фундаментальное ограничение E2EE в веб-приложении, и open source само по себе его не устраняет.
У симплХ действительно есть временные ссылки — механика похожая. Но насколько понимаю, там ссылка одноразовая именно для установления контакта, а сам контакт и чат после этого остаются. Здесь же одноразовым является весь разговор: нет аккаунта/контакта, после Destroy/TTL - комнаты больше нет в принципе, как сущнотси, а ссылка отвечает 410. Session ещё дальше от этой модели — там есть постоянный Account ID.
но в любом случае - пускай существуют - впоросов к ним нет:)
Тема очень интересная и технически реализуемая, НО у нее есть слабые места, закрытие которых тащит за собой утяжеление архитектуры сервиса, а именно (что приходит первым в голову): аутентификация - раза доказывает только знание секрета, но не личность человека., Перебор фраз, люди будут выбирать слабые варианты вроде,а их можно угадывать перебором. Нужна какаяято защита от массовых попыток входа. Более долгое серверное состояние комнаты и его хранение и тд. и тп.
Но повторюсь - звучит без подробностей - интересно.
никакой магии в 30 минут не вкладывается, просто некая продолжительность беседы, ориентировочная. понятно, что в целом можно и расширять её, если на то будет явная потребность
внешний шортнер небезопасно для передачи сикрета стороннему сервису, свой шортнер - можно, но надо идти в усложнение механики, ну и также новые риски открываются
Похоже слишком короткий grace period при уходе мобильного браузера в фон: пока переключаешьмя в другое приложение, чтобы отправить ссылку, websocket может быть приостановлен и комната успевает уничтожиться. Проверю сценарий отдельно — для комнаты, которая ещё ждёт второго участника, действительно логично давать больше времени на возврат.
Все верно, полученную ссылку вам не нужно открывать самому, она одноразовая, т.е. перейти по ней можно один раз. Её необходимо передать второму собеседнику, либо если тестить в одного, то открыть её в новой вкладке\в режиме инкогнито\в другом браузере.
Комментарий хороший, как идея UX, спасибо, но на мой взгляд это предложение открывает целую коробку новых вытекающих проблем - перебор и массовое резервирование номеров, дополнительные лимиты, TTL и защита от создания большого количества ожидающих комнат. В текущей реализации этих рисков почти нет, именно за счёт её простотЫ.
Да, если считать клиентский код доверенным и неизменённым, описанный MITM не получится: handshake аутентифицируется секретом из URL fragment, которого relay-сервер не получает.
Но более общий тезис - верный: поскольку сам 410.chat раздаёт JS, скомпрометированный сервер может отдать изменённый клиент, который уже украдёт secret или plaintext. HTTPS в таком случае не спасает — он лишь подтверждает, что изменённый код действительно пришёл от 410.chat. Это фундаментальное ограничение E2EE в веб-приложении, и open source само по себе его не устраняет.
Я имел в виду по "по дефолту задумки", соррян, криво выразился:)
принимается, но все же здесь концепция - это возравт 410 ошибки, на ней не может быть по дефолту ничего. т.е. неудобоство намеренное, так сказать
но за смысл, конечно, понял)
У симплХ действительно есть временные ссылки — механика похожая. Но насколько понимаю, там ссылка одноразовая именно для установления контакта, а сам контакт и чат после этого остаются. Здесь же одноразовым является весь разговор: нет аккаунта/контакта, после Destroy/TTL - комнаты больше нет в принципе, как сущнотси, а ссылка отвечает 410. Session ещё дальше от этой модели — там есть постоянный Account ID.
но в любом случае - пускай существуют - впоросов к ним нет:)
Тема очень интересная и технически реализуемая, НО у нее есть слабые места, закрытие которых тащит за собой утяжеление архитектуры сервиса, а именно (что приходит первым в голову): аутентификация - раза доказывает только знание секрета, но не личность человека., Перебор фраз, люди будут выбирать слабые варианты вроде,а их можно угадывать перебором. Нужна какаяято защита от массовых попыток входа. Более долгое серверное состояние комнаты и его хранение и тд. и тп.
Но повторюсь - звучит без подробностей - интересно.
Вопрос хороший, и вполне себе может даже и реальный. Без экспретизы - не буду углубляться и рассуждать. На заметку.
о, добрый день)
да, там снесли пост и забанили меня на вечно, да, переключатель языков у меня списке, спасибо
никакой магии в 30 минут не вкладывается, просто некая продолжительность беседы, ориентировочная. понятно, что в целом можно и расширять её, если на то будет явная потребность
внешний шортнер небезопасно для передачи сикрета стороннему сервису, свой шортнер - можно, но надо идти в усложнение механики, ну и также новые риски открываются
Спасибо, это хороший кейс.
Похоже слишком короткий grace period при уходе мобильного браузера в фон: пока переключаешьмя в другое приложение, чтобы отправить ссылку, websocket может быть приостановлен и комната успевает уничтожиться. Проверю сценарий отдельно — для комнаты, которая ещё ждёт второго участника, действительно логично давать больше времени на возврат.
Все верно, полученную ссылку вам не нужно открывать самому, она одноразовая, т.е. перейти по ней можно один раз. Её необходимо передать второму собеседнику, либо если тестить в одного, то открыть её в новой вкладке\в режиме инкогнито\в другом браузере.
Комментарий хороший, как идея UX, спасибо, но на мой взгляд это предложение открывает целую коробку новых вытекающих проблем - перебор и массовое резервирование номеров, дополнительные лимиты, TTL и защита от создания большого количества ожидающих комнат. В текущей реализации этих рисков почти нет, именно за счёт её простотЫ.
Спасибо. Попробую воспроизвести на Андроид + Kiwi. При таком сценарии 410 появляться не должен — посмотрю, что именно ломается.