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.
The first to
raise the alarm was Raymond 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 pageCanceling 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.