Google Chrome API changes could break support for numerous plugins

Greg S

TS Evangelist

Proposed changes to Google Chrome's extension APIs may be about to ruin dozens of plugins if they are implemented. Removal of a blocking mode from web requests will prevent ad blockers from functioning in their intended manner. Security add-ons such as F-Secure will also be broken by Google's intended updates.

First brought to light by uBlock Origin developer Raymond Hill, he describes why uBlock Origin and uMatrix plugins will not be able to be rewritten under the API changes. Google suggests using the more limited DeclaritiveNetRequest API, but its limits are too great to overcome. Blocking media elements over a certain size, selective disabling of JavaScript, and removing Cookies from outgoing data are not possible under the revised APIs. Additionally, lists used by ad blockers would be limited to 30,000 entries under the new API, a rather low limitation when considering how long existing lists already are.

Strangely enough, these API changes are on their way to implementation after Google has beefed up its own ad blocking capabilities within Chrome. Google is pointing to efficiency as reasoning for the proposed changes. Instead of passing web requests to extensions and waiting for processing to happen, requests are handled by Chrome for synchronous handling. This is indeed an optimization that also brings additional security benefit, but at the expense of removing functionality that many users would like to have.

Concerns have been raised over the changes by executives at Ermes Cyber Security as well as software engineers from F-Secure. A developer notes that blocking HTTPS traffic determined to be malicious in nature will no longer be possible. Parental control functions will also be ruined as an unintended consequence. Chief Technical Officer of Ermes calls out Google's 30,000 entry limitation noting that phishing prevention lists can contain millions of URLs, also stating that a lack of ability to update content-blocking lists in real time would be highly detrimental for security reasons.

Giorgio Maone, the developer behind Firefox add-on NoScript, also joined in the conversation and stated that his plugin will not be able to come to Chrome after more than a year of work. NoScript is so well respected for its privacy-enhancing capabilities that the TOR project includes it as a default add-on.

There is one small glimmer of hope for businesses and developers that have highly successful Chrome plugins that are on the brink of ruin. Inside of a design document, there is some recognition that the changes are not all planned out. "It is unlikely this will account for 100% of use cases (e.g., onAuthRequired), so we will likely need to retain webRequest functionality in some form." At worst, there are always plenty of other browsers available to pick from.

Permalink to story.

 

gigantor21

TS Maniac
I am already using Firefox on mobile instead of Chrome because of extensions; perfectly happy to do so on the desktop too, if it comes to that.
 
  • Like
Reactions: xxLCxx

psycros

TS Evangelist
I am already using Firefox on mobile instead of Chrome because of extensions; perfectly happy to do so on the desktop too, if it comes to that.
Firefox did exactly the same thing to its devs not once, but twice. Last time they literally copied Chromium's API and put in some minor extensions, and they will do so again because Mozilla is run by complete *****s who think this is the only way they can stay relevant and make a little money. If they were smart leaders they would do like Apple and embrace user privacy. They won't, of course, because Mozilla's goal is now the same as Google's - to steal your personal information to sell marketers and cyber-criminals. That's all these changes to Chrome are meant to accomplish and anyone who thinks differently is a rare breed of imbecile.
 
Last edited: