Google все же планирует ограничить блокировщики рекламы в Chrome - «Новости»

Xakep #242. Фаззинг

• Содержание выпуска


• Подписка на «Хакер»

Продолжаются споры вокруг Manifest V3, из-за изменений в котором могут пострадать блокировщики контента.

Предыстория

В начале текущего года мы рассказывали о серьезной проблеме, которая обеспокоила разработчиков расширений для блокировки контента в браузерах. Дело в том, что в настоящее время инженеры Google готовят третью версию манифеста (Manifest V3), который определяет возможности и ограничения для расширений.

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

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

В свою очередь, declarativeNetRequest позволяет Chrome (а не самому расширению) решать, как поступать с сетевыми запросами, устраняя при этом «узкое место» и повышая безопасность. Разработчики Google уверены, что использование declarativeNetRequest API будет лучше для приватности пользователей, ведь так расширения более не смогут читать сетевые запросы, сделанные от лица пользователя.

В начале года одним из первых внимание к этой проблеме привлек разработчик популярных блокировщиков uBlock Origin и uMatrix Реймонд Хилл (Raymond Hill). Он предупредил, что отказ от webRequest станет «смертью» для его продуктов, а также выразил опасение, что переход на API declarativeNetRequest может пагубно сказаться на множестве других решений. В итоге точку зрения разработчика поддержали множество его «коллег по цеху», включая создателей NoScript, tampermonkey и защитных решений.

Хилл выражал опасение, что эти перемены могут сказаться и на другой функциональности, к примеру, откажут блокирование медиаэлементов, превышающих заданный размер, и отключение исполнения jаvascript через инжекты Content-Security-Policy директив. Хуже того, по его словам, declarativeNetRequest предлагает разработчикам единственную имплементацию фильтровочного движка, к тому же ограниченную лишь 30 000 фильтров, что не выдерживает сравнения даже с EasyList.

Команда разработчиков Ghostery и вовсе опубликовала исследование, в котором наглядно продемонстрировала, что работа блокировщиков рекламы практически не сказывается на производительности Chrome, хотя представители Google утверждали обратное в комментариях к третьей версии манифеста. Исследователи продемонстрировали бенчмарк-тесты uBlock Origin, Adblock Plus, Brave, DuckDuckGo и Ghostery, которые доказывают, что блокировщики практически не влияют на скорость загрузки страниц. Порой страницы без рекламы грузятся даже быстрее, чем с рекламой.

Последние новости

Обсуждение Manifest V3 по-прежнему продолжается, и теперь с обращением к сторонним разработчикам обратился Симеон Винсент (Simeon Vincen), занимающий должность Developer Advocate for Chrome Extensions, и, по сути, отвечающий за защиту интересов разработчиков расширений.

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

Реймонд Хилл уже ответил на эти заявления, отметив, что блокирующие возможности webRequest API все равно будут ограничены, а Google, по сути, получит возможность диктовать разработчикам свои условия. Он убежден, что если бы дело действительно было в производительности, инженеры Google могли бы пойти по пути Firefox, разрешив возвращать Promise только для трех методов, которые применимы для блокировок. По его мнению, мотивация Google не имеет ничего общего с опытом конечных пользователей, и больше связана с защитой доходов от рекламы.

«Раздражает то, как они продолжают говорить, что “ webRequest API не признают устаревшим”, будто разработчиков волновало именно это, будто они пытаются прикрыть настоящую проблему сфабрикованной, до которой никому нет дела, — пишет Хилл. — Блокировочные возможности webRequest API стали причиной того, что Google передал контроль над блокировкой контента блокировщикам. Чтобы достигнуть своей текущей пользовательской базы, Google Chrome должен был поддерживать блокировщики контента, ведь это самые популярные расширения для любого браузера. Но теперь, когда Google Chrome стал доминирующим браузером на рынке, они находятся в более выгодной позиции и могут сместить баланс между двумя этими целями в сторону основного бизнеса Google».