Google предлагает новый стандарт для веба – Web Bundles. Этот стандарт позволяет «упаковывать» [bundle] все ресурсы веб-сайта в один файл, что не даст браузерам возможности оперировать ссылками на его дочерние ресурсы. Эта система угрожает превратить веб из коллекции ресурсов с гиперссылками (которые можно изучать, безопасно скачивать или даже менять) на непрозрачные «комки» информации в стиле «всё или ничего» (типа PDF или SWF). Организации, пользователи, исследователи и регуляторы, верящие в открытый, прозрачный, удобный для пользователей веб, должны воспротивиться этому стандарту.
Хотя мы признательны за то, что Web Bundles и связанные с ними предложения намерены решить определённые проблемы, мы считаем, что существуют лучшие способы достичь тех же целей, не подвергая опасности открытую, прозрачную, ориентированную на пользователя природу веба. Одна потенциальная альтернатива – использовать подписанные обязательства по независимо скачиваемым подресурсам. На описание альтернатив потребуется отдельная статья, а некоторыми уже поделились с авторами спецификации.
Веб ценен тем, что концентрируется на пользователе, контролируется пользователями, редактируется пользователями. Даже пользователи с небольшим опытом может понять, какие веб-ресурсы есть на странице, и решить, что должен загружать его браузер. Даже если вы не эксперт, вы можете пользоваться этим и устанавливать соответствующие расширения или инструменты для защиты конфиденциальности.
Направленность веба на пользователей отличается от принципов работы большинства приложений и систем распределения информации. Большинство приложений представляют собой скомпилированный набор из кода и ресурсов, которые сложно или даже невозможно отделить друг от друга, чтобы оценивать по отдельности. И это важно отличие объясняет, почему существует так много инструментов для защиты конфиденциальности для веба, и так мало – для «двоичных» приложений.
По сути, то, что делает веб отличным от других систем, более открытым, более сконцентрированным на пользователе, и отличает от других приложений – это URL. Поскольку URL обычно указывает на единственный ресурс, исследователи и активисты могут изучать и делать выводы об этих URL заранее. Другие пользователи могут использовать эту информацию, чтобы принимать решения по поводу того, хотят ли они загружать то, на что указывает URL, и как именно это делать. Что важнее, эксперты могут загрузить tracker.com/code.js, решить, что он нарушает конфиденциальность, и поделиться этой информацией с другими пользователями, чтобы те знали, что не стоит загружать этот код в будущем.
Этому правилу есть исключения, и в платформе веба нет подобных требований – однако обычно от URL ожидается, что они будут практически неизменными. Такие ожидания разбросаны по всей платформе веба – в аспектах политики кэширования, в инструкциях библиотек к развёртыванию кода, и т.п.
Компания Google недавно предложила три взаимосвязанных стандарта – Web Bundles, Signed HTTP Exchanges (иногда сокращаемые до SXG) и Loading. В основном в данной статье под Web Bundles мы будем понимать все три. Пока что Web Bundles рекламируют, как стандарты, которые будут использоваться в рекламных системах (TURTLEDOVE, SPARROW) и в качестве частей будущей системы AMP от Google – хотя, как мне кажется, это только вершина айсберга.
На высоком уровне, Web Bundles – это способ упаковки ресурсов воедино. Вместо того, чтобы скачивать страницы, изображения и файлы JavaScript по отдельности, ваш браузер скачивает весь «пакет» [bundle], файл, в который включена вся информация для загрузки страницы. URL перестают быть распространёнными глобальными ссылками на ресурсы сети, и становятся произвольными индексами внутри пакетов.
Иначе говоря, Web Bundles превращают сайты в аналог PDF (или файлов SWF от Flash). В PDF включены все изображения, видео и скрипты, необходимые для рендера PDF – вы не скачиваете их по отдельности. Это имеет свои преимущества по удобству, однако делает невозможным исследование отдельных частей PDF независимо от всего файла целиком. Поэтому для PDF не бывает блокирующих контент инструментов. PDF – это предложение типа «всё или ничего», а Web Bundles превратят веб-сайты в такие же предложения.
Меняя URL с осмысленных глобальных идентификаторов на произвольные индексы, зависящие от конкретных пакетов, Web Bundles дают рекламщикам и трекерам новые действенные способы обхода инструментов, обеспечивающих конфиденциальность и безопасность. В следующем разделе даются отдельные примеры, поясняющие эту точку зрения.
URL в Web Bundles – произвольные ссылки на ресурсы внутри пакета, а не ссылки на ресурсы с глобальным доступом. Это даёт сайтам несколько способов обхода инструментов, обеспечивающих конфиденциальность и безопасность.
Они, конечно, могут ссылаться на ресурсы за пределами пакета, однако такое поведение будет лишать смысла системы пакетов, поэтому данный вопрос в рамках этой статьи не обсуждается.
Основная возможность обхода проистекает из того, что Web Bundles создаёт локальное пространство имён для ресурсов, независимое от того, что видит весь остальной мир, из-за чего могут возникать всяческие путаницы с именами, перечёркивающие годы работы по улучшению конфиденциальности и безопасности, которой занимались активисты конфиденциальности и исследователи. Далее описывается всего лишь три способа, которые позволят веб-сайтам с поддержкой Web Bundles воспользоваться этой путаницей.
Прежде, если веб-сайт хотел использовать скрипт, отслеживающий действия пользователя, он включал в HTML-страницу тэг <script>, указывающий на один и тот же скрипт с неизменным URL. Исследователи или группы пользователей могли занести этот URL в список типа EasyPrivacy, с тем, чтобы пользователи, беспокоящиеся о своей конфиденциальности, могли посещать этот сайт, не скачивая отслеживающий их скрипт. Сегодня именно так работает большая часть блокирующих инструментов.
Web Bundles облегчают сайтам обход таких инструментов через рандомизацию URL нежелательных ресурсов. То, что в сегодняшнем вебе имеет глобальное название, допустим, example.org/tracker.js, в одном Web Bundles можно назвать 1.js, в другом – 2.js, в третьем – 3.js, и так далее. Web Bundles поощряют эту практику, делая её бесплатной для сайтов. Кэширование становится бессмысленным (поскольку вы раздаёте каждому пользователю все ресурсы и кэшируете весь пакет), а разметку URL поддерживать не обязательно (поскольку в пакете, отправленном пользователю, уже есть рандомизированные URL).
Что ещё хуже, Web Bundles позволят сайтам обходить блокирующие инструменты, сделав так, чтобы в каждом пакете одни и те же URL указывали на разные ресурсы. В текущем вебе, допустим, example.org/ad.jpg, указывает на одно и то же для любого пользователя. Веб-сайту сложно сделать так, чтобы один и тот же URL возвращал две разные картинки. В итоге, блокирующие инструменты могут заблокировать ad.jpg, зная, что блокируют рекламу для всех. Практически нет риска, что для одних это будет реклама, а для других – логотип компании (это сделать не невозможно, но трудно — смысл в том, что Web Bundles превращают методы обхода, сегодня являющиеся сложными и хрупкими, в простые и бесплатные).
Web Bundles опасным образом изменяют эту систему. Example.org может сделать свои пакеты такими, что в одном из них example.org/ad.jpg будет указывать на рекламу, в другом – на логотип сайта, в третьем – на что-то ещё. Это не только значительно усложнит исследователям задачу составления списков, или вообще сделает её невозможной – это даст сайтам новые возможности отравлять списки блокировки.
Наконец, Web Bundles открывают ещё более опасные методы обхода. Сегодня такие группы, как uBlock Origin и Safe Browsing от Google составляют списки URL, включая туда вредоносные и опасные веб-ресурсы. Подобные проекты считают URL единственным, или хотя бы важнейшим идентификатором опасного ресурса. Универсальная и глобальная природа URL делает эти списки полезными.
Web Bundles вновь позволяют сайтам обходить эту защиту, разрешая им ссылаться на известные вредные ресурсы через проверенные URL. В вебе очень сложно заставить сайты относиться к ресурсу cdn.example.org/cryptominer.js так, как если бы это был ресурс cdn.example.org/jquery.js (и наоборот). В Web Bundles это будет тривиальной задачей.
Разработчики и сторонники спецификаций Web Bundles утверждают, что ничего нового тут нет, и все перечисленные способы обхода защиты уже существуют. Технически это так, однако по сути такое утверждение игнорирует экономику процесса, и поэтому не описывает ситуацию в целом. Web Bundles делают эти дорогие, ненадёжные и сложные технологии дешёвыми или даже бесплатными.
К примеру, веб-сайты действительно могут сделать так, чтобы множество URL указывало на один и тот же файл, чтобы усложнить жизнь блокировщикам, но на практике сайтам делать это сложно. Рандомизация URL вредит кэшированию, требует хранения отображения случайных URL на нужные ресурсы и передачи этой информации в CDN, и так далее. Сайты могут это делать, однако это дорого и сложно, поэтому этим занимаются редко.
В том же ключе сегодня сайты могут использовать куки или другие механизмы отслеживания пользователей, чтобы один и тот же URL работал для разных пользователей по-разному, выполняя различные атаки с запутыванием URL, описанные выше. Однако метод этот ненадёжный (что делать с новыми посетителями?), сложный (нужно поддерживать и распространять отображение значений кук и ресурсов) и дорогой (большинство веб-серверов и хостингов полагаются на кэширование, поэтому подобные технологии для сайтов, не принадлежащих крупным корпорациям, практически недоступны).
В целом Web Bundles значительно облегчают нежелательное поведение путём его удешевления.
В данной статье описан вред, который Web Bundles нанесут инструментам конфиденциальности и безопасности. Но с этим и связанными с ним стандартами есть и другие проблемы. В частности это:
Компания Brave работает над улучшением конфиденциальности веба, как в нашем браузере, так и в наших инструментах, которые мы делаем и распространяем, и в пропаганде, которую мы ведём для организаций, занимающихся стандартизацией. Эта статья – лишь один из примеров нашей работы над тем, чтобы стандарты веба и далее концентрировались на конфиденциальности, прозрачности и подчинённости пользователю.
Мы долго, но безрезультатно пытались обратить внимание авторов стандарта Web Bundles на перечисленные проблемы. Мы призываем Google и группу Web Bundles приостановить работу над этим предложением, пока не будут решены проблемы конфиденциальности и безопасности, описанные в статье. Мы также призываем членов сообществ, посвящённых конфиденциальности и безопасности веба, присоединиться к этой дискуссии, и не реализовывать этот стандарт, пока не будут решены описанные проблемы.
Один из способов сделать это – описать эти проблемы в комментариях к записи, которую оставил автор этой статьи в проекте Web Bundles. Другие варианты – сделать новые примечания к спецификациям, сообщить разработчикам вашего браузера, насколько важны лично для вас инструменты защиты конфиденциальности, и какой риск для этих инструментов несут в себе эти новые стандарты.
Хотя мы признательны за то, что Web Bundles и связанные с ними предложения намерены решить определённые проблемы, мы считаем, что существуют лучшие способы достичь тех же целей, не подвергая опасности открытую, прозрачную, ориентированную на пользователя природу веба. Одна потенциальная альтернатива – использовать подписанные обязательства по независимо скачиваемым подресурсам. На описание альтернатив потребуется отдельная статья, а некоторыми уже поделились с авторами спецификации.
Веб – уникальная открытая система, и всё благодаря URL-ссылкам
Веб ценен тем, что концентрируется на пользователе, контролируется пользователями, редактируется пользователями. Даже пользователи с небольшим опытом может понять, какие веб-ресурсы есть на странице, и решить, что должен загружать его браузер. Даже если вы не эксперт, вы можете пользоваться этим и устанавливать соответствующие расширения или инструменты для защиты конфиденциальности.
Направленность веба на пользователей отличается от принципов работы большинства приложений и систем распределения информации. Большинство приложений представляют собой скомпилированный набор из кода и ресурсов, которые сложно или даже невозможно отделить друг от друга, чтобы оценивать по отдельности. И это важно отличие объясняет, почему существует так много инструментов для защиты конфиденциальности для веба, и так мало – для «двоичных» приложений.
По сути, то, что делает веб отличным от других систем, более открытым, более сконцентрированным на пользователе, и отличает от других приложений – это URL. Поскольку URL обычно указывает на единственный ресурс, исследователи и активисты могут изучать и делать выводы об этих URL заранее. Другие пользователи могут использовать эту информацию, чтобы принимать решения по поводу того, хотят ли они загружать то, на что указывает URL, и как именно это делать. Что важнее, эксперты могут загрузить tracker.com/code.js, решить, что он нарушает конфиденциальность, и поделиться этой информацией с другими пользователями, чтобы те знали, что не стоит загружать этот код в будущем.
Этому правилу есть исключения, и в платформе веба нет подобных требований – однако обычно от URL ожидается, что они будут практически неизменными. Такие ожидания разбросаны по всей платформе веба – в аспектах политики кэширования, в инструкциях библиотек к развёртыванию кода, и т.п.
Web Bundles лишают URL смысла
Компания Google недавно предложила три взаимосвязанных стандарта – Web Bundles, Signed HTTP Exchanges (иногда сокращаемые до SXG) и Loading. В основном в данной статье под Web Bundles мы будем понимать все три. Пока что Web Bundles рекламируют, как стандарты, которые будут использоваться в рекламных системах (TURTLEDOVE, SPARROW) и в качестве частей будущей системы AMP от Google – хотя, как мне кажется, это только вершина айсберга.
На высоком уровне, Web Bundles – это способ упаковки ресурсов воедино. Вместо того, чтобы скачивать страницы, изображения и файлы JavaScript по отдельности, ваш браузер скачивает весь «пакет» [bundle], файл, в который включена вся информация для загрузки страницы. URL перестают быть распространёнными глобальными ссылками на ресурсы сети, и становятся произвольными индексами внутри пакетов.
Иначе говоря, Web Bundles превращают сайты в аналог PDF (или файлов SWF от Flash). В PDF включены все изображения, видео и скрипты, необходимые для рендера PDF – вы не скачиваете их по отдельности. Это имеет свои преимущества по удобству, однако делает невозможным исследование отдельных частей PDF независимо от всего файла целиком. Поэтому для PDF не бывает блокирующих контент инструментов. PDF – это предложение типа «всё или ничего», а Web Bundles превратят веб-сайты в такие же предложения.
Меняя URL с осмысленных глобальных идентификаторов на произвольные индексы, зависящие от конкретных пакетов, Web Bundles дают рекламщикам и трекерам новые действенные способы обхода инструментов, обеспечивающих конфиденциальность и безопасность. В следующем разделе даются отдельные примеры, поясняющие эту точку зрения.
Web Bundles позволят сайтам обходить инструменты, обеспечивающие конфиденциальность и безопасность
URL в Web Bundles – произвольные ссылки на ресурсы внутри пакета, а не ссылки на ресурсы с глобальным доступом. Это даёт сайтам несколько способов обхода инструментов, обеспечивающих конфиденциальность и безопасность.
Они, конечно, могут ссылаться на ресурсы за пределами пакета, однако такое поведение будет лишать смысла системы пакетов, поэтому данный вопрос в рамках этой статьи не обсуждается.
Основная возможность обхода проистекает из того, что Web Bundles создаёт локальное пространство имён для ресурсов, независимое от того, что видит весь остальной мир, из-за чего могут возникать всяческие путаницы с именами, перечёркивающие годы работы по улучшению конфиденциальности и безопасности, которой занимались активисты конфиденциальности и исследователи. Далее описывается всего лишь три способа, которые позволят веб-сайтам с поддержкой Web Bundles воспользоваться этой путаницей.
Обход инструментов безопасности через рандомизацию URL
Прежде, если веб-сайт хотел использовать скрипт, отслеживающий действия пользователя, он включал в HTML-страницу тэг <script>, указывающий на один и тот же скрипт с неизменным URL. Исследователи или группы пользователей могли занести этот URL в список типа EasyPrivacy, с тем, чтобы пользователи, беспокоящиеся о своей конфиденциальности, могли посещать этот сайт, не скачивая отслеживающий их скрипт. Сегодня именно так работает большая часть блокирующих инструментов.
Web Bundles облегчают сайтам обход таких инструментов через рандомизацию URL нежелательных ресурсов. То, что в сегодняшнем вебе имеет глобальное название, допустим, example.org/tracker.js, в одном Web Bundles можно назвать 1.js, в другом – 2.js, в третьем – 3.js, и так далее. Web Bundles поощряют эту практику, делая её бесплатной для сайтов. Кэширование становится бессмысленным (поскольку вы раздаёте каждому пользователю все ресурсы и кэшируете весь пакет), а разметку URL поддерживать не обязательно (поскольку в пакете, отправленном пользователю, уже есть рандомизированные URL).
Обход инструментов конфиденциальности посредством повторного использования URL
Что ещё хуже, Web Bundles позволят сайтам обходить блокирующие инструменты, сделав так, чтобы в каждом пакете одни и те же URL указывали на разные ресурсы. В текущем вебе, допустим, example.org/ad.jpg, указывает на одно и то же для любого пользователя. Веб-сайту сложно сделать так, чтобы один и тот же URL возвращал две разные картинки. В итоге, блокирующие инструменты могут заблокировать ad.jpg, зная, что блокируют рекламу для всех. Практически нет риска, что для одних это будет реклама, а для других – логотип компании (это сделать не невозможно, но трудно — смысл в том, что Web Bundles превращают методы обхода, сегодня являющиеся сложными и хрупкими, в простые и бесплатные).
Web Bundles опасным образом изменяют эту систему. Example.org может сделать свои пакеты такими, что в одном из них example.org/ad.jpg будет указывать на рекламу, в другом – на логотип сайта, в третьем – на что-то ещё. Это не только значительно усложнит исследователям задачу составления списков, или вообще сделает её невозможной – это даст сайтам новые возможности отравлять списки блокировки.
Обход инструментов конфиденциальности через сокрытие опасных URL
Наконец, Web Bundles открывают ещё более опасные методы обхода. Сегодня такие группы, как uBlock Origin и Safe Browsing от Google составляют списки URL, включая туда вредоносные и опасные веб-ресурсы. Подобные проекты считают URL единственным, или хотя бы важнейшим идентификатором опасного ресурса. Универсальная и глобальная природа URL делает эти списки полезными.
Web Bundles вновь позволяют сайтам обходить эту защиту, разрешая им ссылаться на известные вредные ресурсы через проверенные URL. В вебе очень сложно заставить сайты относиться к ресурсу cdn.example.org/cryptominer.js так, как если бы это был ресурс cdn.example.org/jquery.js (и наоборот). В Web Bundles это будет тривиальной задачей.
Web Bundles облегчают задачу нарушения конфиденциальности, которая сейчас является сложной
Разработчики и сторонники спецификаций Web Bundles утверждают, что ничего нового тут нет, и все перечисленные способы обхода защиты уже существуют. Технически это так, однако по сути такое утверждение игнорирует экономику процесса, и поэтому не описывает ситуацию в целом. Web Bundles делают эти дорогие, ненадёжные и сложные технологии дешёвыми или даже бесплатными.
К примеру, веб-сайты действительно могут сделать так, чтобы множество URL указывало на один и тот же файл, чтобы усложнить жизнь блокировщикам, но на практике сайтам делать это сложно. Рандомизация URL вредит кэшированию, требует хранения отображения случайных URL на нужные ресурсы и передачи этой информации в CDN, и так далее. Сайты могут это делать, однако это дорого и сложно, поэтому этим занимаются редко.
В том же ключе сегодня сайты могут использовать куки или другие механизмы отслеживания пользователей, чтобы один и тот же URL работал для разных пользователей по-разному, выполняя различные атаки с запутыванием URL, описанные выше. Однако метод этот ненадёжный (что делать с новыми посетителями?), сложный (нужно поддерживать и распространять отображение значений кук и ресурсов) и дорогой (большинство веб-серверов и хостингов полагаются на кэширование, поэтому подобные технологии для сайтов, не принадлежащих крупным корпорациям, практически недоступны).
В целом Web Bundles значительно облегчают нежелательное поведение путём его удешевления.
Иные проблемы
В данной статье описан вред, который Web Bundles нанесут инструментам конфиденциальности и безопасности. Но с этим и связанными с ним стандартами есть и другие проблемы. В частности это:
- У SXG нет системы откатов. Если на сайте сегодня случайно появится вредоносный ресурс, сайт можно будет просто обновить. Если сайт подпишет Web Bundles при помощи SXG, для подписанта нет понятного способа сообщить всем, чтобы они «уже не доверяли этому конкретному пакету».
- Взаимодействие с Manifest v3: Manifest v3 ограничивает возможности расширений использованием шаблонов URL для блокировки. Web Bundles делают эти URL бессмысленными. Объединение двух этих вещей позволит сайтам полностью обходить блокировки.
- Путаница с источниками. Loading + SXG позволяют вам скачать контент с одного сервера, а потом выполнить его с настройками конфиденциальности и безопасности другого сервера. Потенциал путаницы для пользователя тут огромен – и хотя мы уверены, что сотрудники Google активно работают над решением этой проблемы, риск для пользователей остаётся очень большим.
Заключение
Компания Brave работает над улучшением конфиденциальности веба, как в нашем браузере, так и в наших инструментах, которые мы делаем и распространяем, и в пропаганде, которую мы ведём для организаций, занимающихся стандартизацией. Эта статья – лишь один из примеров нашей работы над тем, чтобы стандарты веба и далее концентрировались на конфиденциальности, прозрачности и подчинённости пользователю.
Мы долго, но безрезультатно пытались обратить внимание авторов стандарта Web Bundles на перечисленные проблемы. Мы призываем Google и группу Web Bundles приостановить работу над этим предложением, пока не будут решены проблемы конфиденциальности и безопасности, описанные в статье. Мы также призываем членов сообществ, посвящённых конфиденциальности и безопасности веба, присоединиться к этой дискуссии, и не реализовывать этот стандарт, пока не будут решены описанные проблемы.
Один из способов сделать это – описать эти проблемы в комментариях к записи, которую оставил автор этой статьи в проекте Web Bundles. Другие варианты – сделать новые примечания к спецификациям, сообщить разработчикам вашего браузера, насколько важны лично для вас инструменты защиты конфиденциальности, и какой риск для этих инструментов несут в себе эти новые стандарты.
