Google will not block third-party ad blockers in the browser Chromium

Google still remembered the principle of Don'y be evil and abandoned the planned changes to the API of the Chromium browser , because of which most ad blockers and some other extensions became non-functional .

The decision was made after the publication of the study , how much different ad blockers slow down the work of Chromium (see above). It turned out that these delays are so miserable that they can hardly be considered the reason for the introduction of the new API. A few hours after this, one of the Chromium developers officially announced the decision to postpone the new API.

Recall that the conflict arose because of the new declarativeNetRequest API (part of the Manifest V3 document ) programming interfaces , which make it impossible to fully use the webRequest API . Extensions use API data to block content on the fly during page loading. In the new system, blockers will not be able to block events, but only to view them. Instead, extensions are offered to switch to the declarativeNetRequest API - and inform the browser about the events they want to block. This supposedly should speed up the loading of pages in the browser (because the extensions will no longer slow down the main thread), as well as protect the privacy of users, according to Google.

First raised the alarmRaymond Hill, author of uBlock Origin and uMatrix. He said that his ad blocking extensions “cannot exist” if changes are adopted. Later pessimism was expressed by the developers of other extensions, including F-Secure, NoScript and Ermes Cyber ​​Security. For example, NoScript for Firefox can’t be transferred to Chrome.

Raymond Hill noted that the declarativeNetRequest API is no more than the implementation of one particular filtering engine, and a rather limited implementation (the 30,000 limit is not enough to work out well-known EasyList lists alone). ” Raymond Hill also noted that the new API does not support some other features, including blocking media elements larger than this size, disabling the execution of JavaScript by introducing Content-Security-Policy directives and deleting outgoing cookie headers.

Google claimed that changes are necessary for 1) security; 2) the fast work of the ad blocker built into Chromium, since the current extensions, with their current mechanism of work, slow down the browser, increasing the page rendering time. However, the Adblockers Performance Study study, published on February 15, 2019, completely refutes this thesis.

The study was conducted by the developers of the advertising blocker Ghostery from the German startup Cliqz. Probably, they were especially sad to hear accusations from Google, because their blocker had the least effect on page loading speed, leading in all categories with a pretty good margin. Well, this can be understood, because Ghostery is not really a full-fledged blocker, like, for example, uBlock Origin. In addition, the choice of extensions for testing can also be criticized, but this is not the point. The main thing is that ad blockers practically do not slow down the loading of pages, as many (including Google) thought.

The comparison showed that “the most popular content blockers are already very effective (they have an average decision time for a request of less than 1 millisecond) and should not lead to any overhead costs noticeable to users.” Moreover, a study conducted earlier by The Tracker Tax has shown that ad blocking actually speeds up the loading of pages , in some cases twice .

If we talk about problems, they are connected more with the work of other extensions, rather than blockers.


Diagram from the DebugBear study from December 2018 on how different extensions load the CPU while rendering the page

Canceling Google’s plans is only a temporary fix, said Chrome’s engineer, Chrome, Devlin. After finalizing, Manifest V3 will be returned for discussion, taking into account the requirements of all developers.