Я не согласен что полная анонимность необходима только для людей которые совершают противоправные действия, анонимность необходима всем, кто не хочет тратить лишние деньги, не хочет жить в информационном пузыре, который поисковые сервисы для них курируют, и не хочет лишиться свободы только из за того, что был знаком с кем то не тем, или оказался не в том месте не в то время. На сайте проекта описано как это сегодня все работают - мы уже давно перестали видеть один и тот же интернет и платить одну и ту же цену за одинаковые товары и услуги. Чтобы посмотреть куда двигаются централизованные платформы, посмотрите на системы Social scoring в Китае. Только на днях подписан указ о мониторинге ~9000 СМИ и не только в России. Поэтому позиция что privacy / anonymity нужна только в узких случаях немного устарела, мне кажется.
Идентификаторы не связаны напрямую, но вычисляются, об этом написано даже в официальной статье на сайте.
Не очень пока понимаю о чем это?
передача ключей по стороннему каналу сделает любую систему защищенной от MITM.
Это верно, но другие системы этого просто не позволяют (за редкими исключениями вроде email/PGP)
Вопрос и был в том как это сделать прозрачно для пользователя?
Это будет решать optional identity layer (который тоже не будет раскрывать social graph).
с какого адреса запрашивают какие данные из какой очереди
IP адреса можно/нужно защищать на уровне транспорта - Tor итд
Это же жутко неудобно и непрозрачно для пользователя.
Вы же знаете какого провайдера вы используете для email – почему это неудобно иметь возможно поменять провайдера не теряя никакие контакты при этом (как произойдет в случае с большинством email провайдеров, за исключением случая когда вы используете свой домен)?
Или где-то есть централизованный список всех доступных серверов
Нет, и его не должно быть, иначе это будет централизованная сеть. Есть ли где то список всех email providers?
Можете описать что будет если во время сеанса между А и Б рухнет их общий сервер? "А" полезет выбирать свой другой, "Б" свой другой, как они согласовывать это будут если прямой связи между А и Б больше нет по определению?
1) это событие очень низкой вероятности, и если нет redundancy то придется установить новый контакт 2) будет redundancy.
первоначальное приглашение может быть передано через открытый канал, при условии что он не подменяет информацию - там только публичные ключи и одноразовый адрес – это работает похожим образом на PANDA когда только один пользователь может получить доступ к ресурсу.
вопрос идентификации пользователей ортогонален решаемой проблеме, если вы получили ссылку через канал где вы доверяете идентификации, то это подтверждает identity. но при этом вы скрываете интенсивность коммуникаций итд
да, такая атака возможна, но это очень сложная атака если например вы показываете qr code в видео звонке. Следующая версия (сегодня/завтра будет бета) добавит возможность проверить security code через другой канал.
это не совсем так - этот ключ не должен быть защищен от пассивной атаке - его можно передать через любой канал связи, при двух условиях - 1) вы доверяете что канал не подменяет информацию (что достаточно сложно сделать например при видео звонке) 2) вы можете установить личность получателя/отправителя
то есть можно установить соединение с кем угодно где угодно.
даже в случае если пункт 1 не выполняется, то с версии 4.4 можно проверить security code через какой то независимый от первого канал - если он совпадает, это доказывает что канал не был перехвачен, то есть это добавляет второй фактор.
разница в том что в Briar этот QR code является идентификатором профиля пользователя - он один и тот же для разных пользователей, в SimpleX этот qr code одноразовый (многоразовый тоже можно сделать) и два разных кода не содержать никакой общей информации (кроме адреса relay где создана очередь для сообщений).
Т.е. фактически ID профиля есть. Просто он иногда меняется.
Нет, у профилей нет никаких идентификаторов, идентификатор есть у Вашего соединения с одним контактом только (pairwise identifier), и он иногда меняется. Наличие ID профиля позволило бы двум контактам установить что они общаются с одним и тем же пользователем, в данном случае это невозможно, потому что два разных контакта не видят никаках общих данных кроме display name (которое во-первых low entropy и не уникальное, то есть его совпадение не доказывает что это тот же самый пользователь, во-вторых можно каждому контакту слать случайное display name - для этого есть incognito mode).
Но чтобы сообщения доходили то получается, что нужно либо заново встретится и по блютуз обменяться новыми идентификаторами, либо сервер должен сам знать какой был, а какой стал.
нет, это не так работает. Для переноса коммуникаций с тем же контактом на другой сервер клиент передает адрес новой очереди через зашифрованный канал, прозрачно для пользователей, не надо заново встречаться, это просто часть протокола. При этом старый сервер не знает куда перешли коммуникации, он только видит что очередь удалена, а новый сервер не видит откуда они пришли - для него это просто новое соединение.
он работает не так как другие
это корректное утверждение, SimpleX протокол отличается от всех остальных тем что вместо profile identifiers & user credentials используются temporary pairwise connection identifiers / anonymous credentials. Если вы представите себе ваши коммуникации как граф, где узлы это пользователи, то во всех сетях часть или весь граф пользователя доступен для наблюдения оператором или другим пользователям, в данном случае узлы сети недоступны серверам, серверы только предосталяют односторонние соединения. На сайте (https://simplex.chat) в разделе SimpleX Explained есть картинка которая это объясняет.
Идентификаторы очереди никак не связаны с каким то пользователем на уровне приложения, только на уровне сессии / транспорта, что отдельно решается.
"Запросы на соединение передаются вне сети" - так если так поступать в других системах это тоже защитит их от этой атаки. Но как это сделано тут?
Ссылка с адресом соединения и публичными ключами передается вне сети, дополнительно в следующей версии будет верификация. В других системах согласование ключа происходит через саму систему (за редким исключением типа PGP).
Как обновлять схему при нахождении проблем в текущей (а они обязательно будут)?
В протоколе есть согласование версии, просто добавится поддержка новой версии.
"Серверы не хранят никакой пользовательской информации" - а что мешает им хранить?
То что у них ни в какой момент времени нет никакой пользовательской информации вообще кроме адресов очередей, анонимных ключей для верификации запросов (ED448, которые разные для каждой очереди) и зашифрованных сообщений.
как я узнаю о появлении нового сервера?
так же, как вы узнаете о существовании нового email провайдера например - какие использовать серверы определяется только конфигурацией клиента, сами серверы не формируют сеть – они не знают о существовании других серверов.
Или как новый сервер узнает о появлении меня с моими очередями?
никак, на новом сервере будет просто создана новая очередь, и сообщения тому же контакту будут через нее передаваться, переключение прозрачно для пользователя.
:)))
Я не согласен что полная анонимность необходима только для людей которые совершают противоправные действия, анонимность необходима всем, кто не хочет тратить лишние деньги, не хочет жить в информационном пузыре, который поисковые сервисы для них курируют, и не хочет лишиться свободы только из за того, что был знаком с кем то не тем, или оказался не в том месте не в то время. На сайте проекта описано как это сегодня все работают - мы уже давно перестали видеть один и тот же интернет и платить одну и ту же цену за одинаковые товары и услуги. Чтобы посмотреть куда двигаются централизованные платформы, посмотрите на системы Social scoring в Китае. Только на днях подписан указ о мониторинге ~9000 СМИ и не только в России. Поэтому позиция что privacy / anonymity нужна только в узких случаях немного устарела, мне кажется.
Да!
Не очень пока понимаю о чем это?
Это верно, но другие системы этого просто не позволяют (за редкими исключениями вроде email/PGP)
Это будет решать optional identity layer (который тоже не будет раскрывать social graph).
IP адреса можно/нужно защищать на уровне транспорта - Tor итд
Вы же знаете какого провайдера вы используете для email – почему это неудобно иметь возможно поменять провайдера не теряя никакие контакты при этом (как произойдет в случае с большинством email провайдеров, за исключением случая когда вы используете свой домен)?
Нет, и его не должно быть, иначе это будет централизованная сеть. Есть ли где то список всех email providers?
1) это событие очень низкой вероятности, и если нет redundancy то придется установить новый контакт 2) будет redundancy.
да может и я запутался :)
первоначальное приглашение может быть передано через открытый канал, при условии что он не подменяет информацию - там только публичные ключи и одноразовый адрес – это работает похожим образом на PANDA когда только один пользователь может получить доступ к ресурсу.
вопрос идентификации пользователей ортогонален решаемой проблеме, если вы получили ссылку через канал где вы доверяете идентификации, то это подтверждает identity. но при этом вы скрываете интенсивность коммуникаций итд
да, такая атака возможна, но это очень сложная атака если например вы показываете qr code в видео звонке. Следующая версия (сегодня/завтра будет бета) добавит возможность проверить security code через другой канал.
это не совсем так - этот ключ не должен быть защищен от пассивной атаке - его можно передать через любой канал связи, при двух условиях - 1) вы доверяете что канал не подменяет информацию (что достаточно сложно сделать например при видео звонке) 2) вы можете установить личность получателя/отправителя
то есть можно установить соединение с кем угодно где угодно.
даже в случае если пункт 1 не выполняется, то с версии 4.4 можно проверить security code через какой то независимый от первого канал - если он совпадает, это доказывает что канал не был перехвачен, то есть это добавляет второй фактор.
разница в том что в Briar этот QR code является идентификатором профиля пользователя - он один и тот же для разных пользователей, в SimpleX этот qr code одноразовый (многоразовый тоже можно сделать) и два разных кода не содержать никакой общей информации (кроме адреса relay где создана очередь для сообщений).
Нет, у профилей нет никаких идентификаторов, идентификатор есть у Вашего соединения с одним контактом только (pairwise identifier), и он иногда меняется. Наличие ID профиля позволило бы двум контактам установить что они общаются с одним и тем же пользователем, в данном случае это невозможно, потому что два разных контакта не видят никаках общих данных кроме display name (которое во-первых low entropy и не уникальное, то есть его совпадение не доказывает что это тот же самый пользователь, во-вторых можно каждому контакту слать случайное display name - для этого есть incognito mode).
нет, это не так работает. Для переноса коммуникаций с тем же контактом на другой сервер клиент передает адрес новой очереди через зашифрованный канал, прозрачно для пользователей, не надо заново встречаться, это просто часть протокола. При этом старый сервер не знает куда перешли коммуникации, он только видит что очередь удалена, а новый сервер не видит откуда они пришли - для него это просто новое соединение.
это корректное утверждение, SimpleX протокол отличается от всех остальных тем что вместо profile identifiers & user credentials используются temporary pairwise connection identifiers / anonymous credentials. Если вы представите себе ваши коммуникации как граф, где узлы это пользователи, то во всех сетях часть или весь граф пользователя доступен для наблюдения оператором или другим пользователям, в данном случае узлы сети недоступны серверам, серверы только предосталяют односторонние соединения. На сайте (https://simplex.chat) в разделе SimpleX Explained есть картинка которая это объясняет.
Идентификаторы очереди никак не связаны с каким то пользователем на уровне приложения, только на уровне сессии / транспорта, что отдельно решается.
Ссылка с адресом соединения и публичными ключами передается вне сети, дополнительно в следующей версии будет верификация. В других системах согласование ключа происходит через саму систему (за редким исключением типа PGP).
В протоколе есть согласование версии, просто добавится поддержка новой версии.
То что у них ни в какой момент времени нет никакой пользовательской информации вообще кроме адресов очередей, анонимных ключей для верификации запросов (ED448, которые разные для каждой очереди) и зашифрованных сообщений.
так же, как вы узнаете о существовании нового email провайдера например - какие использовать серверы определяется только конфигурацией клиента, сами серверы не формируют сеть – они не знают о существовании других серверов.
никак, на новом сервере будет просто создана новая очередь, и сообщения тому же контакту будут через нее передаваться, переключение прозрачно для пользователя.
Большое спасибо за статью - пользователь только что прислал ссылку! Сейчас отвечу на вопросы/комментарии!