6 min read

Update: Opera, Brave, Vivaldi have ignored Chrome’s anti-ad-blocker changes, despite shared codebase.

On June 12, Google published a blog post clarifying it’s intentions with ad blocking extension system saying it isn’t trying to kill ad blockers. “This has been a controversial change since the Web Request API is used by many popular extensions, including ad blockers. We are not preventing the development of ad blockers or stopping users from blocking ads. Instead, we want to help developers, including content blockers, write extensions in a way that protects users’ privacy.”

In January, Chrome updated its Manifest V3 extension system that could lead to crippling all ad blockers. Even though Chrome’s Manifest extension system received overwhelmingly negative feedback, Google is standing firm on Chrome’s ad blocking changes. Last week, the company shared a statement on Google groups that current ad blocking capabilities will not be changed. Chrome will still have the capability to block unwanted content, but this will be restricted to only paid, enterprise users of Chrome.

“Chrome is deprecating the blocking capabilities of the webRequest API in Manifest V3, not the entire webRequest API (though blocking will still be available to enterprise deployments).”

What is this Manifest v3 controversy?

Google developers have introduced an alternative to the webRequest API named the declarativeRequest API, which limits the blocking version of the webRequest API. declarativeNetRequest is a less effective, rules-based system. Chrome currently imposes a limit of 30,000 rules, However, most popular ad blocking rules lists use almost 75,000 rules. Although Google claimed that they’re looking to increase this number, they didn’t assure it.

“We are planning to raise these values but we won’t have updated numbers until we can run performance tests to find a good upper bound that will work across all supported devices.”

According to Manifest V3, the declarativeNetRequest API will be treated as the primary content-blocking API in extensions. Chrome developers listed two reasons behind this new update, one was performance and the other was better privacy guarantee to users. What this API does is, allow extensions to tell Chrome what to do with a given request, rather than have Chrome forward the request to the extension. This allows Chrome to handle a request synchronously.

Regarding performance upgrade, however, a study was published on WhoTracks.me who analyzed the network performance of the most commonly used ad blockers: uBlock Origin, Adblock Plus, Brave, DuckDuckGo and Cliqz’z Ghostery.

The study revealed that these content-blockers, except DuckDuckGo, have only sub-millisecond median decision time per request. This small amount of time will not have any overhead noticeable by users. Additionally, the efficiency of content blockers is continuously being improved with innovative approaches or with the help of technologies like WebAssembly.

A uBlock maintainer had earlier reported an issue on the Chromium bug tracker for this feature:

“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.”

In their update, Google wrote that appropriately permissioned extensions will still be able to observe network requests using the webRequest API, which he insisted is “foundational for extensions that modify their behavior based on the patterns they observe at runtime.”

Now, the lead developer of uBlock Origin, Raymond Hill has commented on the situation. Losing the ability to block content with the webRequest API is his main concern.

“This breaks uBlock Origin and uMatrix, [which] are incompatible with the basic matching algorithm [Google] picked, ostensibly designed to enforce EasyList-like filter lists,” he explained in an email to The Register. “A blocking webRequest API allows open-ended content blocker designs, not restricted to a specific design and limits dictated by the same company which states that content blockers are a threat to its business.”

He also called out Google’s business model on uBlock Origin’s GitHub.

“The blocking ability of the webRequest API caused Google to yield control of content blocking to content blockers. Now that Google Chrome is the dominant browser, it is in a better position to shift the optimal point between the two goals which benefits Google’s primary business. The deprecation of the blocking ability of the webRequest API is to gain back this control, and to further now instrument and report how web pages are filtered since now the exact filters which are applied to web page is information which will be collectable by Google Chrome.”

For a number of web users, this was the last straw. Many said they’d be moving on from Chrome to other privacy-friendly browsers.

A comment reads, “If you use an iOS device, Safari is awesome. The integration between all your hardware devices syncing passwords, tabs, bookmarks, reading list, etc. kicks ass. That’s all not to mention its excellent built-in privacy features and that it’s really really fast.”

Another comment reads, “I used to have Firefox. When I heard that even Microsoft was going to use chromium I realized, Firefox is literally the last front ! I installed Firefox and started using it as my main browser.”

Another says, “Genuinely, most people are choosing between privacy and convenience. And with Firefox you don’t need to choose.”

Mozilla’s Firefox has taken this opportunity to attract Chrome users with a new page detailing how to Switch from Chrome to Firefox.

“Switching to Firefox is fast, easy and risk-free. Firefox imports your bookmarks, autofill, passwords and preferences from Chrome.”

The latest Firefox release also comes with a new feature that can help users block fingerprinting coming from ad trackers.

The brave browser also tweeted about Chrome’s development, stating it will block ads regardless of Chrome’s decisions.

Users also appreciated Brave’s privacy features.

Chrome software security engineer Chris Palmer took to Twitter to claim the move was intended to help improve the end-user browsing experience, and paid enterprise users would be exempt from the changes.

Chrome security leader Justin Schuh also said the changes were driven by privacy and security concerns.

Top browsers, Opera, Brave, Vivaldi have ignored Chrome’s anti-ad-blocker changes, despite having a shared codebase.

Read Next

Google Chrome developers “clarify” the speculations around Manifest V3 after a study nullifies their performance hit argument.

Flutter gets new set of lint rules to build better Chrome OS apps

Chromium developers propose an alternative to webRequest API that could result in existing ad blockers’ end

Sugandha Lahoti
Content Marketing Editor at Packt Hub. I blog about new and upcoming tech trends ranging from Data science, Web development, Programming, Cloud & Networking, IoT, Security and Game development.