Google still insists on restricting the API required by ad blockers

Simeon Vincent corresponding to the Chrome team, commented on Google's current position in regards to Google's Manifest V3 as for the additions to block ad blockers.

Y has stated that the company does not intend to abandon the original plan to stop supporting the blocking mode of the webRequest API, that allows you to change received content on the fly. An exception will only be made for Chrome for Enterprises, in which support for the webRequest API will be preserved as before.

Google wants ad blockers out

For regular users of the Chrome API, webRequest will be limited to read-only mode. In the WebRequest replacement for content filtering offered by the declarative NetRequest API, it covers only a limited part of the features used in modern blocker advertising.

In fact, instead of the handlers themselves with full access to network requests, there is a ready and integrated filtering engine that processes the blocking rules with its own resources.

For example, the declarativeNetRequest API does not allow you to use your own filtering algorithms and does not allow you to create complex rules that overlap each other based on conditions.

The developers jointly prepared a list of comments that listed the API declarativeNetRequest flaws.

Google agreed with many comments and added declarativeNetRequest API. In particular, the added support for dynamic changes and added rules, provided the ability to remove HTTP headers, but only those whitelisted (Referer, Cookie, Set-Cookie).

Plans include support for adding and replacing HTTP headers (for example, for overriding Set-Cookie and CSP directives) and the ability to remove and replace request parameters.

The preview version of the Manifest V3 defining the list of features and resources provided by the Chrome plugins, is planned to be used in the experimental versions of Chrome Canary in the coming months.

Google does not give convincing arguments for blocking

Raymond HillMore, author of uBlock Origin and uMatrix, commented harshly the answer de a representative of Google and hinted that Google is trying to promote its business interests in the field of Internet advertising and thus obtain control over the mechanisms of its filtration and justify these actions before the general public.

Since you never received a convincing argument to stop popular developers among ad block plugins.

According to Raymond, the drop in performance is not an argument, as the pages load slowly due to their own code and not due to the use of webRequest blocking mode in properly implemented plugins.

If Google was really concerned about performance, they would have modified the web request based on the Promise mechanism, similar to the web request implementation in Firefox.

According to Raymond, Google's strategy is to determine the optimal balance between expansion of the Chrome user base and the commercial damage caused by the use of content blockers.

For him, Google wants to prevent its advertising-related activities from being interrupted at all costs and to the point of rendering ad blockers ineffective on your Chrome browser.

In the first stage of Chrome's expansion, Google was forced to support ad blockers, as some of the most popular plugins among users. But after Chrome took a dominant position, the company tried to change the balance in its favor.

The webRequest API interferes with this goal, as control over content blocking is now in the hands of third-party ad blocker developers.

The absence of the ability to change HTTP headers, cookies, and request parameters (for example, to cut Referer, _utm, and tracker identifiers) is also mentioned, but Google has already promised to remove these comments.