Chrome Browser Developers termination of support for the blocking mode of the webRequest API, which allows you to change the received content on the fly and is actively used in add-ons for blocking ads,
protection against malware, phishing, spying activity, parental control and privacy.
Google motives:
- Blocking API behavior leads to high resource consumption.
When using this API, the browser first sends all the data contained in the network request to the add-on, the add-on analyzes them and returns the modified version for further processing in the browser or issues blocking instructions. In this case, the main delays do not occur at the stage of traffic processing by the add-on, but due to overhead costs for coordinating the execution of the add-on. In particular, such manipulations require the launch of a separate process to complement, as well as the use of IPC to interact with this process and data serialization mechanisms; - The add-on completely controls all traffic at a low level, which opens up extensive opportunities for abuse and privacy violations. According to Google statistics, 42% of all detected malicious add-ons used the webRequest API. It is noted that an average of 1800 malicious add-ons are blocked in the Chrome Web Store catalog every month. Unfortunately, peer review does not allow to catch all malicious add-ons without exception, therefore, in order to increase protection, it was decided to restrict add-ons at the API level. The main idea is to provide add-ons with access not to all traffic, but only to the data that is necessary to implement the intended functionality. In particular, to block content, it is not necessary to give the add-on full access to all sensitive user data;
- Declarative API replacement proposed takes care of all the work of high-performance content filtering and only requires add-ons to load filtering rules. At the same time, the add-on cannot interfere with the traffic and the user's private data remains inviolable;
- Google took into account many of the concerns regarding the lack of functionality of the declarativeNetRequest API and expanded the limit on the number of filtering rules from the originally proposed 30 thousand per extension to a global maximum of 150 thousand, and also added the ability to dynamically change and add rules, remove and replace HTTP headers ( Referer, Cookie, Set-Cookie) and request parameters;
- For enterprises, the possibility of using the blocking mode of operation of the webRequest API has been left, since the policy for applying add-ons is determined by the administrator, who understands the features of the infrastructure and is aware of the risks. For example, the specified API can be used in enterprises to account for employee traffic flows and integrate with internal systems;
- Google's goal is not to stifle and suppress ad blocking add-ons, but to enable the creation of more secure and performant ad blockers;
- The reluctance to leave the blocking behavior of the webRequest API along with the new declarativeNetRequest is due to a desire to restrict access to sensitive data by add-ons. If the webRequest API is left as is, then most add-ons will not use the more secure declarativeNetRequest, as usually when choosing between security and functionality, the majority of developers will choose functionality.
:
- Conducted by add-on developers show an insignificant performance impact on the performance of ad-blocking add-ons (during testing, the performance of various add-ons was compared, but without taking into account the overhead of an additional process that coordinates the execution of handlers in the blocking mode of the webRequest API);
- It is not advisable to completely stop supporting an API that is actively used in add-ons. Instead of deleting, you can add a separate permission and tightly control the adequacy of its use in add-ons, which would save the authors of many popular add-ons from completely reworking their products and avoid cutting functionality;
- To reduce overhead, you can not remove the API, but remake it based on the Promise mechanism, similar to the webRequest implementation in Firefox;
- The proposed declarativeNetRequest alternative does not cover all the needs of developers of ad blocking and security/privacy add-ons, as it does not provide full control over network requests, does not allow the use of custom filtering algorithms, and does not allow the use of complex rules that overlap depending on conditions;
- With the current state of the declarativeNetRequest API, it is impossible to recreate the existing functionality of the uBlock Origin and uMatrix add-ons unchanged, and also makes further development of the NoScript port for Chrome meaningless;
- Concern about privacy is far-fetched, since the non-blocking mode of the webRequest API, which works in read-only mode, has been left and still allows malicious add-ons to control all traffic, but does not allow them to interfere with it on the fly (change content, put their ads, run miners and analyze the content of the input forms is possible even after the page has finished loading);
- Browser Developers , ΠΈ , built on the Chromium engine, intend to leave support for the blocking webRequest mode in their products.
Source: opennet.ru