Not only uBlock Origin, but also other extensions will suffer from new APIs in Chromium
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.
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 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 multimedia elements larger than the specified size, Disable JavaScript execution by introducing Content-Security-Policy directives and removing 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.
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 saidthat if you accept these changes, it 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.
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 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 multimedia elements larger than the specified size, Disable JavaScript execution by introducing Content-Security-Policy directives and removing 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 saidthat if you accept these changes, it 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.