Google’s proposed Chrome extension API changes have developers riled up

Under the guise of improving UX and privacy, Google’s proposed API changes could break ad blockers and other Chrome extensions.

(Editor's note: see bottom of article for update.)

Google is looking to make a move that would dial back how much power some Chrome extensions have, but it may come at the cost of killing many currently available ad block extensions.

I previously outlined how current Chrome permissions allowed extensions way more access than they often need. There are only three risk levels and medium/high seem pretty invasive (even if it makes sense that some extensions would need a certain level of access to run):

  • High: access to all data on your computer and websites you visit
  • Medium: access to your data on all the websites you visited
  • Low: access to your location, browsing activity and history, bookmarks, and list of installed apps, themes, and extensions

Now, Google will likely adjust an existing API and introduce a new one, reducing content blocking extensions’ capabilities.

Google’s proposed changes

You can learn about all the changes in the Chrome extension manifest v3 doc. Extension developers are sounding the alarm around a change to the webRequest API (which may get deprecated completely eventually) and introduction of the declarativeNetRequest API.

The current webRequest API allows extensions to block network requests, as well as modify or redirect them, such as blocking large on-page media and disabling JavaScript execution. Google wants to make it just observational, removing blocking capabilities.

The new declarativeNetRequest API will change the current process of Chrome forwarding network requests to extensions and instead have the extensions tell the browser what to do with requests. Google says this will improve user privacy (extensions won’t have access to details of each network request) and efficiency.

The new API will also limit the number of filtering rules allowed (30,000 max), Raymond Hill, uBlock developer said in a comment on the Chromium bug forum. This would make it difficult to use EasyList due to how many rules it has.

Developers and users voice complaints

The Manifest v3 document has been publicly available since late last year, but it wasn’t until Raymond commented in last week about the declarativeNetRequest API and how it would effectively break their ad blocker.

Raymond was not alone; he just appears to have been the spark that got others talking. AdGuard co-founder Andrey Meshkov added that the new API, nothing would get initially blocked when users visit a website.

While content blockers would be the most affected, they’re not alone. Security extension developers also spoke up about how the API would negatively affect privacy, antivirus, and parental control extensions.

While most of the discussions that I saw online were negative, I did see SwiftonSecurity tweet that this might not be entirely bad news, at least from a user perspective, but that they would wait to see once it gets implemented before making up their mind.

Google told Gizmodo that nothing is yet set in stone and they are willing to listen to developers. So, the backlash may get the search giant to reconsider how strongly they update the manifest.

Some of the proposed changes don’t sound bad

The limited review process for Chrome extensions, combined with all the power they can have, means that they carry a degree of risk that makes us very wary about ever using them. So, it’s good to see Google making progress in fixing something they seemed to be ignoring until recently. Manifest v3 does have some positive moves I can get behind. A few of the changes include disallowing remotely hosted code, reducing background services to just ServiceWorkers, and pushing for extensions to use optional permissions at runtime (this already exists, but few extensions use it).

Still, the change to one API and addition of a new, more restrictive one does leave us looking at them with a cynical eye. Google may be changing things to prevent more of their ads from being blocked. Some developers are saying that while several popular content blockers would be broken by the declarativeNetRequest API, Adblock Plus wouldn’t be one of them and that the changes would specifically keep it working. (They’re replying to Twitter threads claiming they would also be hurt by the API.) Adblock Plus is known to work with companies to whitelist ads from their blocking filters. Plus, a few days before this made news, it came out that Google and Adblock Plus parent company Eyeo GmbH had amended a “whitelisting contract.”

Given the backlash, it’s hard to see Google moving forward with manifest v3 in its current iteration, but we’ll see. In the meantime, maybe it’s time Chrome users consider moving or returning to Firefox? Mozilla made it easier to block ads natively, added tracking protection, and has improved their browser enough that some security experts are more willing to recommend it.

Chrome engineer Devlin Cronin announced in February that the webRequest API would not be fully removed after all. Developers originally claimed that ad blockers slowed down webpage loading due to network requests. Well, the Ghostery ad block team decided to put this to the test and put together a study that benchmarked results. Basically, they discovered that ad blockers barely impacted user experience. So, in the end Google backed down.

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

This quickly leads into some much larger questions. I definitely feel sketched out by the idea of installing a random extension, even from the store, but then there are complaints when things get locked down. So they're damned if they do, and damned if they don't, and meanwhile we're getting into the same open vs. closed debate that's been going on forever.

On a more local level, though, I'm glad to see these changes, but I'd sure like to see some culling of some of the lower-quality listings in the extension store.