Simeon Vincent, Chrome Extensions Developer Advocate, Chrome Team Lead, Google's current position on the third revision of the Chrome manifest, many add-ons to block inappropriate content and ensure security. The company does not intend to abandon the original plan to stop supporting the blocking mode of operation of the webRequest API, which allows you to change the accepted content on the fly. An exception will be made only for the enterprise edition of Chrome (), which will keep the webRequest API support intact.
For regular Chrome API users will be limited to read-only mode. A declarative API has been proposed to replace the webRequest API for content filtering , which covers only a limited part of the features used in modern ad blockers. In fact, instead of its own handlers that have full access to network requests, a ready-made universal built-in filtering engine is offered that processes blocking rules on its own. 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 depending on conditions.
The developers of ad-blocking add-ons have jointly prepared , which listed the shortcomings of the declarativeNetRequest API. Google agreed with many of the comments and added the declarativeNetRequest API. In particular, support has been added for dynamically changing and adding rules, and it has been possible to remove HTTP headers, but only those in the white list (Referer, Cookie, Set-Cookie). There are plans to implement support for adding and replacing HTTP headers (for example, for substituting Set-Cookie and CSP directives) and the ability to remove and replace request parameters.
A draft version of the third version of the manifest, which defines the list of features and resources provided by Chrome add-ons, is planned to be used for testing in experimental builds of Chrome Canary in the coming months.
At the same time, the motivation for prohibiting changes to the accepted content through the webRequest API remains not entirely clear. Claims that the blocking mode of the webRequest API has a negative impact on performance, as the browser waits for the completion of the completion handler before the page is rendered, does not stand up to scrutiny. Previously conducted The performance of ad-blocking add-ons has shown that the latency they introduce is negligible. On average, the use of a blocker slows down the execution of a request by only a fraction of milliseconds, which is negligible against the general background.
The second argument, related to the desire to protect users from uncontrolled access to content add-ons, also does not look convincing, since instead of removing the long-established and common functionality in legitimate add-ons, you could add a new type of permission and give the user the final choice, install an add-on that has full access to network requests or not. In addition, Google has left support for using the webRequest API in read-only mode, allowing full traffic monitoring, but not low-level interference with it.
Add-ons can change the content of downloaded web pages through other APIs (for example, malicious add-ons can still deliver their ads, run miners and analyze the content of input forms).
Raymond Hill, author of the uBlock Origin and uMatrix unwanted content blocking systems, is tough enough the response of a Google representative and hinted at demagogy and behind-the-scenes games in which Google, under the guise of a good opportunity, is trying to advance its business interests in the field of online advertising, gain control over its filtering mechanisms and justify these actions in the eyes of the general public.
He never received convincing arguments for the need to stop the widely used and popular API among developers of add-ons. In Raymond's opinion, performance degradation is not an argument, since pages load slowly due to their bloat, and not due to the use of blocking webRequest mode in correctly implemented add-ons. If Google really cared about performance, they would have redesigned webRequest based on the , by analogy with webRequest in Firefox.
According to Raymond, Google's strategy is to strike the right balance between expanding the user base of Chrome and the business damage caused by the use of content blockers. At the first stage of Chrome's expansion, Google had to put up with ad blockers as one of the most popular add-ons among users. But after Chrome gained dominance, the company tried to tip the balance in its favor and gain control of blocking by promoting to embed inappropriate ad blocking in Chrome. The webRequest API defeats this purpose, as content blocking control is now in the hands of third-party ad blocker developers.
Source: opennet.ru