Для обычных пользователей Chrome API webRequest будет ограничен режимом только для чтения. На замену API webRequest для фильтрации контента предложен декларативный API declarativeNetRequest, который покрывает лишь ограниченную часть возможностей, используемых в современных блокировщиках рекламы. По сути вместо собственных обработчиков, имеющих полный доступ к сетевым запросам, предлагается готовый универсальный встроенный движок для фильтрации, собственными силами обрабатывающий правила блокировки. Например, API declarativeNetRequest не позволяет использовать собственные алгоритмы фильтрации и не даёт возможность создавать сложные правила, перекрывающие друг друга в зависимости от условий.
Разработчики дополнений для блокировки рекламы совместно подготовили список замечаний, в котором перечислили недостатки API declarativeNetRequest. Google согласился со многими замечаниями и дополнил API declarativeNetRequest. В частности, добавлена поддержка динамического изменения и добавления правил, обеспечена возможность удаления HTTP-заголовков, но только находящихся в белом списке (Referer, Cookie, Set-Cookie). В планах реализация поддержки добавления и замены HTTP-заголовков (например, для подстановки Set-Cookie и директив CSP) и возможность удаления и замены параметров запросов.
Предварительный вариант третьей версии манифеста, который определяет перечень возможностей и ресурсов, предоставляемых дополнениям Chrome, планируется в ближайшие месяцы применить для тестирования в экспериментальных сборках Chrome Canary.
При этом остаётся не совсем понятной мотивация запрета изменения принимаемого контента через API webRequest. Заявления, что блокирующий режим API webRequest негативно сказывается на производительности, так как перед выводом страницы браузер ожидает полного завершения работы обработчика дополнения, не выдерживают критики. Ранее проведённые тесты производительности дополнений для блокирования рекламы показали, что вносимая ими задержка ничтожна. В среднем применение блокировщика замедляет выполнение запроса лишь на доли миллисекунд, что пренебрежимо мало на общем фоне.
Второй аргумент, связанный с желанием защитить пользователей от неконтролируемого доступа дополнений к контенту, также не выглядит убедительным, так как вместо удаления давно сложившейся и распространённой в легитимных дополнениях функциональности можно было добавить новый тип полномочий и предоставить пользователю конечный выбор, устанавливать дополнение, имеющего полный доступ к сетевым запросам или нет. Кроме того, Google оставил поддержку использования API webRequest в режиме только для чтения, позволяющем выполнять полный мониторинг трафика, но не вмешиваться в него на низком уровне. Изменять же содержимое загруженных web-страниц дополнения могут через другие API (например, вредоносные дополнения как и раньше могут поставлять свою рекламу, запускать майнеры и анализировать содержимое форм ввода).
Рэймонд Хилл (Raymond Hill), автор систем блокирования нежелательного контента uBlock Origin и uMatrix, достаточно жестко прокомментировал ответ представителя Google и намекнул на демагогию и закулисные игры, в которых Google под видом благой возможности пытается продвинуть свои бизнес-интересы в области интернет-рекламы, получить контроль за механизмами её фильтрации и оправдать эти действия в глазах широкой публики.
Убедительных доводов в необходимости прекращения широко распространённого и востребованного среди разработчиков дополнений API он так и не получил. По мнению Рэймонда падение производительности не является доводом, так как страницы загружаются медленно из-за своей раздутости, а не из-за использования блокирующего режима webRequest в корректно реализованных дополнениях. Если бы Google волновала действительно производительность, они бы переделали webRequest на основе механизма Promise, по аналогии с реализацией webRequest в Firefox.
По мнению Рэймонда стратегия Google заключается в определении оптимального баланса между расширением пользовательской базы Chrome и ущербом бизнесу, наносимому из-за использования блокировщиков контента. На первом этапе экспансии Chrome компания Google вынуждена была мириться с блокировщиками рекламы, как одними из самых востребованных среди пользователей дополнений. Но после того, как Chrome занял доминирующие позиции, компания попыталась сместить баланс в свою пользу и получить контроль над блокировкой, начав продвигать инициативу по встраиванию в Chrome функции блокирования неприемлемой рекламы. API webRequest мешает данной цели, так как сейчас контроль над блокировкой контнента находится в руках разработчиков сторонних блокировщиков рекламы.
Дополнение: Разработчики Privacy Badger опубликовали список недостатков API declarativeNetRequest и третьей версии манифеста. Кроме ограничения API webRequest также отмечается возникновение проблем с изменением модели запроса полномочий - дополнение не сможет активироваться сразу для всех страниц (убрано полномочие "all_urls"), а будет работать только в контексте активной вкладки, т.е. пользователю понадобиться подтверждать работу дополнения для каждого сайта. Также упоминается отсутствие в declarativeNetRequest возможности изменения HTTP-заголовков, Cookie и параметров запросов (например, чтобы вырезать Referer, _utm и идентификаторы трекеров), но данные замечания Google уже пообещал устранить.
Начало
Вход
Регистрация