Партнёр ищет переписку с собой, а её нет — да, это провал. Поэтому выше уже обсудили: правильнее не генерировать полностью фейковую базу, а прятать только помеченные чаты, остальное показывать как есть. Тогда переписка с партнёром на месте, просто без тех диалогов, которые ты заранее скрыл.
«Нет сети» при доскролле — элегантно, записал. Лучше чем обрыв на пустом месте.
Про следователя с досье — согласен, против целевого расследования с подготовкой decoy не поможет. Но panic mode и не про это. Он про массовые проверки: погранконтроль, рутинный досмотр, бытовые ситуации. Там не сверяют досье, а листают на месте и решают за минуту.
По сути вы правы: аэропорт, рутинная проверка, ревнивый партнёр — вот реалистичные кейсы. Следователь с ордером — нет. И честно говоря, от такого сценария не спасёт ни один мессенджер.
Да, вы правы — поведенческая часть сейчас самое слабое место. 12 сообщений и шаблонные тексты не выдержат реального допроса, тут спорить нечего.
Идея с отображением реальных чатов минус помеченные — сильнее. Ты знаешь контекст, можешь ответить на вопросы, вкладка с медиа живая. Для погранконтроля и бытовых сценариев это убедительнее любой генерации.
Буду делать: пользователь заранее помечает «приватные» чаты, по panic PIN они просто исчезают, остальное — как есть. Спасибо за фидбэк.
Всё верно, и это описано в статье — ограничения 12.1 и 12.2. Если атакующий получил полный дамп БД (включая global_salt из admin_settings), он перебирает C(n,2) пар и раскрывает весь граф. При 1000 пользователях — ~500k попыток, на современном железе это секунды.
Pair_hash защищает не от этого сценария. Он защищает от ситуации, когда утекла часть данных — бэкап anonymous_messages без admin_settings, лог-файлы, реплика read-only. Или когда доступ к БД есть, а к таблице с солью — нет (разные схемы/роли в PostgreSQL).
Правильное решение — вынести соль в HSM (HashiCorp Vault, AWS KMS) так, чтобы компрометация PostgreSQL не давала ключ для раскрутки хешей. Это в планах, но честно — пока не реализовано.
Спасибо, что проверяете — именно для этого код открыт.
Юрий, по сути вы описали onion routing (Tor) + garlic routing (I2P). И да, это сильнее, чем что-либо на уровне приложения — я об этом честно написал в разделе 11.
Идея с дроблением файлов по разным цепочкам вообще красивая — убирает корреляцию по размеру пакетов. Взял на заметку, спасибо.
Но вот почему я пока пошёл другим путём: в Tor каждый hop — это +1–5 секунд задержки. В мессенджере, где человек видит «печатает...» и ждёт ответ через секунду, это больно. I2P ещё медленнее. Плюс для реальной анонимности нужно много независимых узлов — если их мало, вся схема рассыпается. А телефон relay-узлом быть не может — батарея и мобильный трафик не позволят.
Metadata Guard — это то, что реально работает сегодня в рамках клиент-серверной модели, без внешних зависимостей. Onion routing — следующая ступень, но это отдельный большой проект. Пока в roadmap'е — федерация (шаг в эту сторону).
Согласен, в идеальном мире — P2P mesh (типа Yggdrasil/CJDNS) и никакого центрального сервера. Но три практические проблемы:
Оффлайн-доставка — получатель спит, кто хранит сообщение? Нужен store-and-forward узел, а это по сути сервер (Session/Lokinet так и делает через Service Nodes)
Мобильники — NAT, sleep через 30 сек, push только через FCM/APNs = третья сторона всё равно
Группы — 200 человек через mesh = O(n²) соединений или relay-узел
В roadmap'е есть федеративный протокол — шаг в эту сторону. Полный P2P — следующий, но с честным компромиссом: «сообщение доставится, когда получатель онлайн».
Как бы вы решали оффлайн-доставку без доверенных узлов?
Ну я бы так не сказал что это успешный стартап, так как щас много пользователей читают онлайн через другие платформы, где могут купить подписку за 100 рублей на месяц и иметь католог с более 1 милиона книг.
А еще делаем учет, что этот стартап арентируеться на людей с 30+, так как молодежь обычно не читает или просто идет в библиотеку, ну или просто покупает подписку в том же онлайн сервисе.
Хорошие замечания, разберу по порядку.
Партнёр ищет переписку с собой, а её нет — да, это провал. Поэтому выше уже обсудили: правильнее не генерировать полностью фейковую базу, а прятать только помеченные чаты, остальное показывать как есть. Тогда переписка с партнёром на месте, просто без тех диалогов, которые ты заранее скрыл.
«Нет сети» при доскролле — элегантно, записал. Лучше чем обрыв на пустом месте.
Про следователя с досье — согласен, против целевого расследования с подготовкой decoy не поможет. Но panic mode и не про это. Он про массовые проверки: погранконтроль, рутинный досмотр, бытовые ситуации. Там не сверяют досье, а листают на месте и решают за минуту.
По сути вы правы: аэропорт, рутинная проверка, ревнивый партнёр — вот реалистичные кейсы. Следователь с ордером — нет. И честно говоря, от такого сценария не спасёт ни один мессенджер.
Да, вы правы — поведенческая часть сейчас самое слабое место. 12 сообщений и шаблонные тексты не выдержат реального допроса, тут спорить нечего.
Идея с отображением реальных чатов минус помеченные — сильнее. Ты знаешь контекст, можешь ответить на вопросы, вкладка с медиа живая. Для погранконтроля и бытовых сценариев это убедительнее любой генерации.
Буду делать: пользователь заранее помечает «приватные» чаты, по panic PIN они просто исчезают, остальное — как есть. Спасибо за фидбэк.
Всё верно, и это описано в статье — ограничения 12.1 и 12.2. Если атакующий получил полный дамп БД (включая
global_saltизadmin_settings), он перебирает C(n,2) пар и раскрывает весь граф. При 1000 пользователях — ~500k попыток, на современном железе это секунды.Pair_hash защищает не от этого сценария. Он защищает от ситуации, когда утекла часть данных — бэкап
anonymous_messagesбезadmin_settings, лог-файлы, реплика read-only. Или когда доступ к БД есть, а к таблице с солью — нет (разные схемы/роли в PostgreSQL).Правильное решение — вынести соль в HSM (HashiCorp Vault, AWS KMS) так, чтобы компрометация PostgreSQL не давала ключ для раскрутки хешей. Это в планах, но честно — пока не реализовано.
Спасибо, что проверяете — именно для этого код открыт.
Юрий, по сути вы описали onion routing (Tor) + garlic routing (I2P). И да, это сильнее, чем что-либо на уровне приложения — я об этом честно написал в разделе 11.
Идея с дроблением файлов по разным цепочкам вообще красивая — убирает корреляцию по размеру пакетов. Взял на заметку, спасибо.
Но вот почему я пока пошёл другим путём: в Tor каждый hop — это +1–5 секунд задержки. В мессенджере, где человек видит «печатает...» и ждёт ответ через секунду, это больно. I2P ещё медленнее. Плюс для реальной анонимности нужно много независимых узлов — если их мало, вся схема рассыпается. А телефон relay-узлом быть не может — батарея и мобильный трафик не позволят.
Metadata Guard — это то, что реально работает сегодня в рамках клиент-серверной модели, без внешних зависимостей. Onion routing — следующая ступень, но это отдельный большой проект. Пока в roadmap'е — федерация (шаг в эту сторону).
Согласен, в идеальном мире — P2P mesh (типа Yggdrasil/CJDNS) и никакого центрального сервера. Но три практические проблемы:
Оффлайн-доставка — получатель спит, кто хранит сообщение? Нужен store-and-forward узел, а это по сути сервер (Session/Lokinet так и делает через Service Nodes)
Мобильники — NAT, sleep через 30 сек, push только через FCM/APNs = третья сторона всё равно
Группы — 200 человек через mesh = O(n²) соединений или relay-узел
В roadmap'е есть федеративный протокол — шаг в эту сторону. Полный P2P — следующий, но с честным компромиссом: «сообщение доставится, когда получатель онлайн».
Как бы вы решали оффлайн-доставку без доверенных узлов?
Ну я бы так не сказал что это успешный стартап, так как щас много пользователей читают онлайн через другие платформы, где могут купить подписку за 100 рублей на месяц и иметь католог с более 1 милиона книг.
А еще делаем учет, что этот стартап арентируеться на людей с 30+, так как молодежь обычно не читает или просто идет в библиотеку, ну или просто покупает подписку в том же онлайн сервисе.