Всем, кого интересует движение за повторную децентрализации Интернета, просто необходимо посмотреть и обдумать выложенное на YouTube 43-минутное выступление Мокси Марлинспайка (Moxie Marlinspike) на тему «Экосистема меняется: Проблемы, стоящие перед распределенными и децентрализованными технологиями» (The Ecosystem Is Moving: Challenges For Distributed And Decentralized Technology, https://www.youtube.com/watch?v=Nj3YFprqAr8 ). Вывод Марлинспайка следующий: «Я не вполне оптимистичен в отношении будущего децентрализованных систем, - и я также очень хотел бы ошибиться в своей оценке».
Мокси Марлинспайк (Moxie Marlinspike)
Видеозапись выступления Марлинспайка (на английском языке, имеются субтитры)
Я сам потратил почти два десятилетия на создание и промышленную эксплуатацию системы LOCKSS (от Lots of Copies Keep Stuff Safe - «Множество копий гарантирует сохранность», https://www.lockss.org/ ) – довольно небольшой системы, которая была задумана как полностью децентрализованная, но эта цель так и не была в полной мере достигнута.
Я согласен с выводом Марлинспайка, и примерно в таком же духе я писал, как минимум, в 2014 году в своём посте «Экономический эффект масштаба в одноранговых сетях» (Economies of Scale in Peer-to-Peer Networks, http://blog.dshr.org/2014/10/economies-of-scale-in-peer-to-peer.html ). Всегда приятно найти кого-то, кто пришел к такому же выводу совершенно иным путем, как это было в случае с экспертом по масштабируемости Тоддом Хоффом (Todd Hoff, см. http://highscalability.com/blog/2018/8/22/what-do-you-believe-now-that-you-didnt-five-years-ago-centra.html ) в 2018 году, а теперь – с Мокси Марлинспайком, который опирается на свой опыт создания системы обмена зашифрованными сообщениями Signal ( https://signal.org/ ). Далее я сравниваю его причины для скептицизма с моими собственными.
Выступление Марлинспайка состоит из двух частей. Основная мысль первой части [см. на отметке 4 мин. 33 сек.] заключается в том, что «ожидания пользователей в отношении программного обеспечения быстро эволюционируют, и быстрое развитие конфликтует с децентрализацией». Он приводит рад примеров централизованных систем, которые эволюционировали быстрее своих децентрализованных конкурентов, включая Slack в сравнении с IRC, Facebook в сравнении с электронной почтой и WhatsApp в сравнении с XMPP. Децентрализованные протоколы [см. на отметке 6 мин. 04 сек.] «застряли во времени», в то время, как централизованные протоколы постоянно обновляются.
О чём Марлинспайк не упоминает, но что дополнительно подкрепляет его точку зрения - это тот факт, что многие методы, обычно используемые при разработке централизованных систем для улучшения удобства их использования, например, A/B-тестирование (A/B testing, https://ru.wikipedia.org/wiki/A/B-тестирование ), трудно, если вообще возможно, применить в отношении децентрализованных систем. Далее, децентрализация связана со значительными накладными расходами по сравнению с централизованной версией такой же системы. Например, совершенно нереалистична идея о том, что «децентрализованный Twitter» отнимет долю рынка у Twitter – у такого решения отсутствовали бы используемые Twitter методы выяснения предпочтений пользователей, оно бы намного медленнее, чем Twitter, внедряло и развертывало подобные функциональные возможности, которые после развертывания работали бы также медленнее.
Одна из основных причин медленности децентрализованного решения была указана Полом Викси (Paul Vixie) в 2014 году в его статье «Состояние, ограничивающее скорость» (Rate-limiting State, https://queue.acm.org/detail.cfm?id=2578510 ). Если децентрализованные системы не вводят ограничения по скорости, как это делает Биткойн, то они уязвимы для того, что фактически является разновидностями DDoS-атак различного типа. Я обсуждал эту проблему в посте «Ограничения скорости» (Rate-Limits, https://blog.dshr.org/2018/06/rate-limits.html ). В результате децентрализованные системы будут замедляться не только из-за накладных расходов на децентрализацию, но и из-за необходимости искусственно ограничивать скорость работы системы в качестве защитной меры.
- Защита неприкосновенности частной жизни
- Сопротивление цензуре
- Доступность
- Контроль
Неприкосновенность частной жизни и защита персональных данных [8:01]
Марлинспайк начинает с того, что отмечает: «Большинство децентрализованных систем в мире по умолчанию не использует шифрование». Это связано с тем, что проблемы управления ключами и сертификатами значительно сложнее в P2P-системе, где необходимо реализовать что-то вроде «Паутины доверия» PGP (Web of Trust – см. также https://ru.wikipedia.org/wiki/Web_of_Trust - Н.Х.), - чем в централизованной системе.
Сторонники децентрализации под «неприкосновенностью частной жизни» (privacy) подразумевают как конфиденциальность данных (data privacy), которая обеспечивается с помощью шифрования, так и конфиденциальность метаданных (metadata privacy), реализуемую посредством «владения данными» (data ownership). Последнее означает, что каждый пользователь владеет и управляет своим собственным сервисом, который содержит его данные. Марлинспайк отмечает, что такой подход выглядит устаревшим, «пережитком тех времен, когда компьютеры существовали для компьютерных специалистов». Подавляющему большинству пользователей для этого не хватает необходимых знаний и навыков. Хотя у самого Марлинспайка такие знания и навыки есть, и [см. 9:57] он действительно управляет собственным почтовым сервером, это не обеспечивает конфиденциальности значимых данных или метаданных, поскольку «каждое электронное письмо, которое я отправляю или получаю, на другом конце попадает в Gmail». Таким образом, у Google есть копии (почти) всех его электронных писем.
По его словам, для реальной защиты данных требуется сквозное шифрование, в то время, как защита метаданных требует инноваций. И то, и другое быстрее будет реализовано в централизованных системах, потому что они могут меняться быстрее. Решение Signal обеспечивает защиту метаданных посредством частных групп, частного обнаружения контактов и конфиденциальности сведений об отправителе, поэтому централизованная служба не может видеть состояние группы и состава её членов, а также того, кто с кем общается. Марлинспайк даёт [см. 10:52] увлекательное описание криптографии, на основе которой строятся частные группы.
Он говорит [см. 16:01]: «P2P-решения не обязательно обеспечивают защиту неприкосновенности частной жизни». Первоначально голосовые и видеозвонки в системе Signal осуществлялись на основе P2P-взаимодействия в рамках прямого контакта между сторонами. Однако пользователи встревожились: «Вы говорите нам, что кто-то может просто позвонить мне и узнать мой IP-адрес?» В общем, теперь звонки маршрутизируются через сервис, однако, поскольку поддерживается сквозное шифрование, сервис не может видеть контент. Он действительно знает IP-адреса сторон, но злоумышленнику придется взломать сервер, чтобы однозначно установить их IP-адреса.
Сопротивление цензуре [17:09]
Используемая Марлинспайком модель цензуры заключается в том, что цензор, - например Великий китайский защитный экран (Great Firewall), - блокирует доступ к сервисам, которые он не одобряет. Проблема здесь в том, что если сервис может быть обнаружен пользователем, то он может быть обнаружен и цензором. К тому же, учитывая автоматизацию, даже если поставщиков сервиса имеется несколько, вполне вероятно, что цензор сможет обнаружить их по крайней мере так же быстро, как и пользователи, - что приводит к известной игре «дай по голове вылезшему из норы кроту» (whack-a-mole). Но в ситуации, если каждый провайдер идентифицирует пользователей независимо, то каждый раз, когда цензор вынуждает пользователей переключиться, им приходится реконструировать свою социальную сеть. Это асимметричная игра, в которой цена для цензора намного меньше, чем для пользователей.
Централизованные сервисы типа WhatsApp и Signal, используют такие методы, как сегментирование прокси (proxy sharding - каждый пользователь может обнаруживать только небольшое подмножество точек доступа), чтобы цензуру было сложно быстро обнаружить все точки доступа к сервисам; а также «маскировка доменом» (domain fronting, https://en.wikipedia.org/wiki/Domain_fronting ), - чтобы сделать затратной блокировку точек доступа, которые цензор сумел обнаружить. Но базовым требованием для защиты от такого рода цензуры является быстрое реагирование [см. 21:07], что затруднительно обеспечить в децентрализованной системе.
Марлинспайк не обсуждает ещё один способ сопротивления цензуре – сопротивляемость децентрализованных систем, таких, как блокчейн-решения, к удалению данных.
(Окончание следует, см. http://rusrim.blogspot.com/2020/10/2.html )
Дэвид Розенталь (David Rosenthal)
Источник: DSHR's Blog
https://blog.dshr.org/2020/09/moxie-marlinspike-on-decentralization.html
Комментариев нет:
Отправить комментарий