Веб-запрос и декларативный сетевой запрос: объяснение влияния на расширения в Manifest V3

В рамках работы по повышению безопасности и конфиденциальности пользователей Chrome планирует внести ряд изменений в платформу расширений. Мы объявили о некоторых из этих изменений в октябре прошлого года и предоставили дополнительную информацию о них сегодня. Эти изменения в платформе внедряются как часть Manifest V3 - следующей версии платформы Chrome Extensions.

Одним из этих изменений является переход от блокирующей версии API веб-запросов к новому API, называемому декларативным сетевым запросом. Было много путаницы и заблуждений относительно мотивов и последствий этого изменения, включая предположение, что эти изменения были разработаны, чтобы предотвратить или ослабить блокировщики рекламы. Это совершенно не так. На самом деле, это изменение призвано дать разработчикам возможность создавать более безопасные и эффективные блокировщики рекламы.

Чтобы улучшить гарантии безопасности и конфиденциальности платформы расширений, мы переосмысливаем некоторые основные API-интерфейсы платформы расширения. Вот почему мы планируем заменить API блокирующих веб-запросов на API декларативного сетевого запроса.

Как работает веб-запрос

С помощью веб-запроса Chrome отправляет все данные в сетевом запросе на расширение для прослушивания, включая любые конфиденциальные данные, содержащиеся в этом запросе, например личные фотографии или электронные письма. Расширение имеет возможность оценить запрос, а затем сообщить Chrome, что делать с запросом: разрешить, заблокировать или отправить его с некоторыми изменениями. В результате расширения, использующие API веб-запросов, обычно имеют доступ для чтения и манипулирования всем, что пользователь делает в Интернете.

Хотя этот API используется хорошими разработчиками для реализации мощных функций, таких как блокировщики контента, он также может использоваться и подвергался злоупотреблению. Поскольку все данные запроса доступны расширению, злоумышленнику очень легко злоупотреблять доступом к учетным данным пользователя, учетным записям или личной информации. С января 2018 года 42% вредоносных расширений используют API веб-запросов.

В дополнение к этим проблемам безопасности, существуют также значительные эксплуатационные расходы. В большинстве случаев эти затраты связаны не с оценкой событий обработки сценария расширения, а скорее со всем, что координирует сценарий. Это общее влияние на производительность может быть очень значительным даже для расширения, написанного настолько эффективно, насколько это возможно, когда время выполнения JavaScript незначительно.

Как это было разработано сегодня, блокирующая версия API веб-запросов требует постоянного, продолжительного процесса и принципиально несовместима с «ленивыми» процессами - процессами, которые можно устанавливать или сносить по мере необходимости, сохраняя ценные системные ресурсы. Существуют также значительные расходы, связанные с сериализацией данных запроса, межпроцессным взаимодействием, необходимым для отправки этих данных в расширения, и обработкой ответов расширения.

Введите декларативный чистый запрос

API декларативного сетевого запроса работает не так, как API веб-запроса. Вместо того, чтобы Chrome отправлял всю информацию о запросе к прослушивающим расширениям во время запроса, расширения регистрируют правила, которые сообщают Chrome, что делать, если видны определенные типы запросов.

Этот подход имеет преимущества как для безопасности пользователя и конфиденциальности, а также производительности. При декларативном подходе Chrome не нужно предоставлять конфиденциальные данные расширению. Браузер может выполнить действие, запрошенное расширением, не отправляя ему все данные, связанные с сетевым запросом, поскольку расширение уже указало условия, при которых предпринимаются различные действия. Это позволяет расширению выполнять блокировку контента без необходимости доступа ко всей личной информации пользователя.

Это имеет значительные последствия для производительности. Самое главное, что постоянный, длительный процесс больше не нужен, потому что правила регистрируются до того, как запросы сделаны, а не нужно обрабатывать их во время выполнения. Это также снижает затраты на сериализацию всех данных запроса и передачу межпроцессных сообщений на прослушивающие добавочные номера. Эти улучшения производительности сделают расширения значительно более жизнеспособными на платформах с ограниченными ресурсами.

Почему не оба?

В дополнение к проблемам производительности, о которых говорилось выше, команда Chrome твердо убеждена, что пользователям не нужно раскрывать свои электронные письма, фотографии, социальные сети или любые другие конфиденциальные данные расширению, если расширение фактически не нуждается в таком доступе для выполнения своего расширения. функция. И исторически, когда разработчикам расширений предоставляется выбор между возможностями и безопасностью, подавляющее большинство разработчиков выбирают возможности. Мы неоднократно видели это на платформе расширений со страницами событий, дополнительными разрешениями и activeTab.

Для предприятий

Предприятиям, школам и предприятиям часто требуются различные средства управления сетью и программным обеспечением для соответствия корпоративным политикам. Кроме того, в этих организациях обычно есть администраторы, роль которых состоит в том, чтобы понимать и настраивать свою среду.
Chrome обеспечивает управление предприятием с помощью политик администратора. Блокирующая версия API веб-запросов остается доступной для управляемых расширений из-за глубокой интеграции, которую предприятия могут иметь между своими наборами программного обеспечения и Chrome. Системные администраторы могут продолжать бесплатно управлять Chrome в корпоративных средах, используя предоставленные ОС механизмы для развертывания политик Chrome .

Движение вперед

Декларативный Net Request и весь Manifest V3 все еще находятся в процессе проектирования и разработки. Мы продолжаем повторять его, отвечая на отзывы сообщества и работая с разработчиками, чтобы помочь поддержать различные варианты использования.

Со времени первоначального объявления API декларативного сетевого запроса мы добавили в API значительную функциональность в результате этих обсуждений. API декларативного сетевого запроса теперь позволяет регистрировать и удалять динамические правила, указанные во время выполнения, а не статически в манифесте. Мы также добавили возможность удалять общие заголовки отслеживания, такие как Referer, Cookie и Set-Cookie.

Мы активно изучаем другие способы расширения этого API, в том числе добавляем методы для получения отзывов о согласованных правилах и поддерживаем более богатые перенаправления, используя манипулирование URL-адресами и регулярные выражения. Кроме того, в настоящее время мы планируем изменить предел правил с максимальных 30 тыс. Правил на расширение до глобального максимального значения 150 тыс. Правил.

Мы продолжим работу с сообществом разработчиков в будущем. Мы понимаем, что принятие Manifest V3 потребует от разработчиков обновления своих расширений, и мы будем продолжать поддерживать их в течение этого перехода.

Автор: Симеон Винсент, разработчик для Chrome Extensions

Перевод статьи: Web Request and Declarative Net Request: Explaining the impact on Extensions in Manifest V3