Karlston Posted January 23, 2019 Share Posted January 23, 2019 Google is working on the Chrome extension manifest version 3 at the moment which defines the capabilities of Chrome's extensions platform. The updated manifest is available as a draft currently that anyone may access. Draft means that it is not set in stone yet and that things may change. Google will release the updated version of the manifest eventually though and make it mandatory after a transitional period. Interested users and extension developers may follow the tracking bug, issue 896897, on the Chromium Bugs website. Raymond Hill, known as Gorhill online, the author of the popular content blockers uBlock Origin and uMatrix, voiced his concern over some of the planned changes; these changes, if implemented as proposed currently, remove functionality that the extensions use for content blocking. Google plans to remove blocking options from the webRequest API and asks developers to use declarativeNetRequest instead. One of the main issues with the suggested change is that it made to support AdBlock Plus compatible filters only and would limit filters to 30k. Hill mentioned on Google's bug tracking site that the change would end his extensions uBlock Origin and uMatrix for Google Chrome. While it would be possible to switch to the new functionality, it is too limiting and would cripple existing functionality of the content blocking extensions. If this (quite limited) declarativeNetRequest API ends up being the only way content blockers can accomplish their duty, this essentially means that two content blockers I have maintained for years, uBlock Origin ("uBO") and uMatrix, can no longer exist. There are other features (which I understand are appreciated by many users) which can't be implemented with the declarativeNetRequest API, for examples, the blocking of media element which are larger than a set size, the disabling of JavaScript execution through the injection of CSP directives, the removal of outgoing Cookie headers, etc. -- and all of these can be set to override a less specific setting, i.e. one could choose to globally block large media elements, but allow them on a few specific sites, and so on still be able to override these rules with ever more specific rules. The new API would limit content blockers for Chrome-based browsers and eliminate options to create new and unique content blocking extensions. All that would be left are AdBlock Plus like filtering extensions that would all offer the same blocking functionality. While there would still be adblockers for Chrome, the limit of 30,000 network filters would make even those less capable than before. EasyList, a very popular blocking list, has 42,000 filters and if users add other lists used for other purposes, e.g. social blocking, that number would increase even more. You can follow the discussion on uBlock Origin's GitHub page as well. Closing Words Could this have been Google's plan all along? Create a web browser and use it to combat the use of content blockers? Block some annoying ads, allow basic content blockers, and block any other form of content blocking to make sure that Google's advertising business improves again? Some users would certainly move to Firefox if uBlock Origin, uMatrix, and other content blockers would no longer work in Chrome-based browsers. Even if millions would migrate, it would still leave Chrome dominate the entire desktop browser market. It will also be interesting to see how Opera, Vivaldi, Brave, and other Chromium-based browser developers react to the change, if it passes the way it is proposed right now. Source: Chrome Extension Manifest V3 could end uBlock Origin for Chrome (gHacks - Martin Brinkmann) Link to comment Share on other sites More sharing options...
Karlston Posted January 24, 2019 Author Share Posted January 24, 2019 Apparently Google's changes will affect more than just ad-blockers... Chrome extensions for antivirus products, parental control enforcement, and various privacy-enhancing services also affected. 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. Source: Chrome API update will kill a bunch of other extensions, not just ad blockers (ZDNet) Link to comment Share on other sites More sharing options...
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. Source: Chrome API update will kill a bunch of other extensions, not just ad blockers (ZDNet)
mp68terr Posted January 24, 2019 Share Posted January 24, 2019 22 hours ago, Karlston said: It will also be interesting to see how Opera, Vivaldi, Brave, and other Chromium-based browser developers react to the change, if it passes the way it is proposed right now. Not using chrome per se, also wondering how chromium-based browsers will react and maybe change their way. Here vivaldi and palemoon with Hill's addons. Link to comment Share on other sites More sharing options...
steven36 Posted January 25, 2019 Share Posted January 25, 2019 Looks like Firefox may get millions of new users soon when they remove Chrome .. i told everyone this was coming back when they started talking about a builtin Adblocker ..What did you expect from a vendor who's cash cow is making ads ? They make more money from making ads and harvesting and selling the data to there sponsors than they do anything else . it all started with them removing YouTube extensions with and API update years before, because people could download the videos without having to look at ads,. You sell your soul to cooperate greed and you end up using locked down software . look at the Windows UWP and Apple's Walled Garden .They build things in mind to take your freedom and privacy away . look at IE it never had no extensions and it was a monopoly for years but Firefox gained millions of users because of it. The past is repeating itself . Link to comment Share on other sites More sharing options...
3175x175(CURRENT).thumb.jpg.b05acc060982b36f5891ba728e6d953c.jpg)
Recommended Posts
Archived
This topic is now archived and is closed to further replies.