Симеон Вінцент (Simeon Vincent), що відповідає в команді Chrome за взаємодію з розробниками доповнень (займає посаду Extensions Developer Advocate), поточну позицію Google щодо третьої редакції маніфесту Chrome, багатьох доповнень для блокування небажаного контенту та забезпечення безпеки. Компанія не має наміру відмовлятися від початкового плану припинення підтримки блокуючого режиму роботи API webRequest, що дозволяє міняти контент, що приймається, на льоту. Виняток буде зроблено лише для редакції Chrome для підприємств (), в яких підтримка API webRequest буде збережена у попередньому вигляді.
Для звичайних користувачів Chrome API буде обмежено режимом лише для читання. На заміну API webRequest для фільтрації контенту запропоновано декларативний API , що покриває лише обмежену частину можливостей, що використовуються у сучасних блокувальниках реклами. По суті замість власних обробників, що мають повний доступ до мережевих запитів, пропонується готовий універсальний вбудований двигун для фільтрації, що власноруч обробляє правила блокування. Наприклад, 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 на основі механізму , за аналогією з webRequest у Firefox.
На думку Реймонда стратегія Google полягає у визначенні оптимального балансу між розширенням користувальницької бази Chrome і збитком бізнесу, який завдається через використання блокувальників контенту. На першому етапі експансії Chrome компанія Google змушена була миритися з блокувальниками реклами як одними з найбільш затребуваних серед користувачів доповнень. Але після того, як Chrome зайняв домінуючі позиції, компанія спробувала змістити баланс на свою користь і отримати контроль над блокуванням, почавши просувати із вбудовування в Chrome функції блокування неприйнятної реклами. API webRequest заважає цієї мети, тому що зараз контроль над блокуванням контнента знаходиться в руках розробників сторонніх блокувальників реклами.
Джерело: opennet.ru