Chrome API update will kill a bunch of other extensions, not just ad blockers
A planned update to one of the Google Chrome extensions APIs would kill much more than a few ad blockers, ZDNet has learned, including browser extensions for antivirus products, parental control enforcement, and various privacy-enhancing services.
Developers for extensions published by F-Secure, NoScript, Amnesty International, and Ermes Cyber Security, among others, made their concerns public today after news broke yesterday that Google was considering the API change.
Their criticism echoed concerns from Raymond Hill, the author of the uBlock Origin and uMatrix ad blockers, who first raised the issue with Chrome developers yesterday in a bug report.
Hill pointed out that Google’s decision to restrict Chrome’s script blocking capabilities to the new DeclarativeNetRequest API [1, 2] instead of the old webRequest API would reduce his ad blocker’s ability to block certain scripts, including scripts used by advertising firms.
The change would also most likely impact all other ad blockers as well, according to Andrey Meshkov, the co-founder of AdGuard, another ad blocker for Chrome.
Regular Chrome users and tech news sites were quick to criticize Google, which just two weeks ago announced that it was expanding Chrome’s built-in ad blocker to worldwide users starting with July 2019. Many pointed out that the Chrome API modification came just at the right moment to cripple and neuter competing ad blockers.
But according to new criticism published today, this would impact far more types of extensions than just ad blockers.
Chrome security plugins also affected
The biggest of these categories would be extensions developed by antivirus makers and meant to prevent users from accessing malicious sites and for detecting malware before it’s being downloaded.
“In addition to ad blocking this seems to affect also security software that rely on extension capabilities of dynamically blocking https traffic that is rated as malicious or otherwise harmful for user,” said Jouni Korte, Senior Software Engineer for Finnish antivirus maker F-Secure.
“This includes pages spreading mal/spy/whateverware, but also for example parental control type of functions, i.e. protecting (child) user from content categorized as harmful/unwanted for him/her,” he said.
The F-Secure developer’s opinion that this would impact almost all security-related Chrome extensions was also echoed by Claudio Guarnieri, Senior Tehnologist at Amnesty International.
“I would also like to echo what Jouni just said. I believe these changes will prevent numerous security extensions from functioning correctly,” said Guarnieri.
“If these changes are published, [my] extension will cease to function,” said Brandon Dixon, the author of the Blockade.io Chrome extension that blocks drive-by attacks and prevents users from accessing phishing sites.
“Proposed changes in the manifest will remove our ability to serve vulnerable communities at scale. Please reconsider the changes to the webRequest blocking capabilities,” Dixon said.
Similar opinions were also expressed by Kristof Kovacs, one of the developers of a child protection extension, the makers of the Privowny extension that provides a wide range of internet privacy-enhancing features, but also by the team at Ermes Cyber Security, the makers of another security-focused Chrome extension that blocks users from accessing known phishing sites.
NoScript’s Chrome port may never land
Last but not least, Giorgio Maone, the maker of the NoScript Firefox add-on also chimed in and pointed out that if this new API rolls out, he won’t be able to release the long-awaited Chrome version of NoScript, on which he’s been working for more than a year.
The NoScript Firefox add-on has a mythical reputation amongst security professionals, and many have been asking Maone for a Chrome version for years.
NoScript, is so good at blocking JavaScript code, that’s it’s one of the extensions included by default with the privacy-hardened Tor Browser. If Chrome developers go ahead with the planned changes, there may never be a NoScript version for Chrome, mainly because NoScript wouldn’t be able to work just as efficiently as it does on Firefox.
Google will change its mind if users push back
The good news is that the criticism of the new DeclarativeNetRequest API came at the right time, in a period when Chrome developers are intentionally open to outside feedback, before going forward with implementing the proposed API in the Chromium code, the browser engine at the heart of Chrome, Vivaldi, Opera, Brave, and other browsers.
“This change _IS NOT INTENDED TO GIMP AD BLOCKERS_. Rather, it is designed to make them faster and more secure. (Yes, even despite the limitations that might impact uBlock.),” said Andrew Meyer, one of the Chromium engineers. “The new proposed content blocking API _is not final_ and can/will be changed.”
The question now remains if Google will back down after the enormous pushback from both end users and extension developers.
After the company was caught secretly logging users into Chrome accounts whenever they accessed a Google site, Google is on very thin ice with most of its users. Crippling third-party ad blockers while launching their own is a terrible look for the browser maker, one that many users won’t be likely to forgive.
More browser coverage:
READ MORE HERE