Over the years, Google Chrome has changed in many ways, some good, some not so much. Google is proposing a new change to Chrome that arguably falls into the latter category as it will adversely affect the functionality of ad blocker extensions like uBlock Origin and AdGuard.

While the internet is not the same Wild West it was a few short years ago with flashing ads for lewd websites, pop-ups and pop-unders, and more polluting your favorite websites, there are plenty of people out there who still won’t use Google Chrome without an ad blocker (hopefully unblocking sites they wish to support). As the tech behind ads has improved, so too have the blockers, with projects like EasyList that not only prevent the ad from loading, but can also make the page appear as if it never had an ad.

Google is proposing a broad set of changes to Chrome’s extension platform, called Manifest V3, the arrival of which we’ve been expecting since late last year. Among other things, Manifest V3 will stop most ad blockers from working as they’re currently able to. Today, ad blockers use Chrome’s “webRequest” API to block certain HTTP requests from ever being made at all, but Chrome needs to check with each relevant extension before processing a request. This adds a (sometimes significant) delay, which Google is trying to avoid.

Under the proposed new design, Google Chrome ad blocker extensions will be forced to use a new “declarativeNetRequest” API which is styled after Adblock Plus’s blocking method, and is limited to 30,000 rules (EasyList alone is well over this 30,000 limit). Beyond that, by styling like Adblock Plus, other ad blockers like uBlock Origin which work on a different system are prevented from working as intended.

The creator of uBlock Origin, Raymond Hill, understandably came out against these changes on the associated Chromium bug, sharing his strong belief that the new extension API is not being designed in favor of users.

Extensions act on behalf of users, they add capabilities to a *user agent*, and deprecating the blocking ability of the webRequest API will essentially decrease the level of user agency in Chromium, to the benefit of web sites which obviously would be happy to have the last word in what resources their pages can fetch/execute/render.

With such a limited declarativeNetRequest API and the deprecation of blocking ability of the webRequest API, I am skeptical “user agent” will still be a proper category to classify Chromium.

A Google spokesperson indicated to us that the new design is not yet set in stone, leaving open the possibility for feedback from the community. (Google updated their statement this morning to further clarify that they are working with developers on the extension Manifest V3 changes.)

These changes are in the design process, as mentioned in the document and the Chromium bug. We want to make sure all fundamental use cases are still possible with these changes and are working with extension developers to make sure their extensions continue to work.

Clearly, Google is working with the developers of the most popular Chrome extensions, beyond just ad blockers, to ensure that all necessary use cases for extensions are still covered under the new APIs. Otherwise, they risk losing some of their power user audience to Firefox.

Check out 9to5Google on YouTube for more news:

FTC: We use income earning auto affiliate links. More.

Check out 9to5Google on YouTube for more news:

You’re reading 9to5Google — experts who break news about Google and its surrounding ecosystem, day after day. Be sure to check out our homepage for all the latest news, and follow 9to5Google on Twitter, Facebook, and LinkedIn to stay in the loop. Don’t know where to start? Check out our exclusive stories, reviews, how-tos, and subscribe to our YouTube channel

About the Author

Kyle Bradshaw

Kyle is an author and researcher for 9to5Google, with special interests in Made by Google products, Fuchsia, and Stadia.

Got a tip or want to chat? Twitter or Email. Kyle@9to5mac.com

Kyle Bradshaw's favorite gear