For three months, Chromium developers
are discussing new
declarativeNetRequest APIs that 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, the 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 notes that the declarativeNetRequest API uses an Adblock Plus-style filtering system that is not compatible with uBlock Origin. He believes that this is a fundamental mistake: “In addition to the fact that uBlock Origin and uMatrix cannot exist, it is a matter of concern that the proposed declarativeNetRequest APIs block the introduction of new content filtering engines on the innovation architecture, because the declarativeNetRequest API is no more than the implementation of one particular the filtering engine, and a rather limited implementation (the limit of 30,000 restrictions 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. Raymond believes that these changes are not in the interests of users.
According
to Andrei Meshkov , co-founder of another AdGuard ad blocker for Chrome, this change is likely to affect all other ad blockers.
Not only blockers
In addition to blockers, anti-virus extensions will be severely affected. “In addition to blocking ads, this will apparently affect software, which relies on dynamic blocking of https traffic, which is rated as malicious,” said Juni Korte, lead software engineer at the Finnish antivirus vendor F-Secure. “These are pages that spread malware, as well as, for example, parental control functions, that is, to protect a user from content classified as harmful / undesirable for him.”
The developer’s opinion was supported by Claudio Guarnieri, a leading specialist of the human rights organization Amnesty International: “I would like to repeat what Juni said. I believe that these changes will impede the proper functioning of numerous security extensions, ”he
wrote .
“If these changes are published, [my] extension will cease to function,” Brandon Dickson, the author of the Blockade.io extension, has
joined his colleagues , blocking drive-by attacks and preventing access to phishing sites.
Similar opinions were expressed by
Christophe Kovacs , one of the developers of the parental control
extensions , the
creators of the Privowny extension , which provides a wide range of functions to increase privacy on the Internet, and the
Ermes Cyber Security team, the creators of another security-oriented Chrome extension.
The author of the popular NoScript extension for Firefox
said that if he accepts these changes, he will not be able to transfer NoScript to Chrome.
Critics believe that Google, under a false pretext, is actually trying to limit the functionality of third-party ad blockers in order to promote the blocker built into the browser, which the company
recently announced . And also to control - which ads can be blocked by users, and which ones can not.
The good news is that the criticism of the new DeclarativeNetRequest API came at the right time, when developers from Google are open to feedback. It is hoped that they will change their mind and abandon the implementation of the new API in the Chromium code on which Chrome, Vivaldi, Opera, Brave and other browsers are based.