Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon

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

Save for later
  • 4 min read
  • 18 Feb 2019

article-image

On Friday, a study was published on WhoTracks.me where the performance of the most commonly used ad blockers was analyzed. This study was motivated by the recent Manifest V3 controversy, which reveals that Google developers are planning to introduce an update that could lead to crippling all ad blockers.

What update Chrome developers are introducing?


The developers are planning to introduce an alternative to the webRequest API named the declrativeNetRequest API, which limits the blocking version of the webRequest API. According to Manifest V3, the declarativeNetRequest API will be treated as the primary content-blocking API in extensions. The 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.

One of the ad blocker maintainers have 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.

What the study by Ghostery revealed?


This study addresses the performance argument made by the developers. For this study, the Ghostery team 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.

Unlock access to the largest independent learning library in Tech for FREE!
Get unlimited access to 7500+ expert-authored eBooks and video courses covering every tech area you can think of.
Renews at €18.99/month. Cancel anytime

How Google developers reacted to this study and all the feedbacks surrounding Manifest V3?


Following the publication of the study and after looking at the feedbacks, Devlin Cronin, a Software Engineer at Google, clarified that these changes are not really meant to prevent content blocking. Cronin added that the changes listed in Manifest V3 are still in the draft and design stage.

In the Google group, Manifest V3: Web Request Changes, Cronin said, “We are committed to preserving that ecosystem and ensuring that users can continue to customize the Chrome browser to meet their needs. This includes continuing to support extensions, including content blockers, developer tools, accessibility features, and many others. It is not, nor has it ever been, our goal to prevent or break content blocking.

The team is not planning to remove the webRequest API. Cronin added, “In particular, there are currently no planned changes to the observational capabilities of webRequest (i.e., anything that does not modify the request).” Based on the feedback and concerns shared, the Chrome team did do some revisions including adding support for the dynamic rule to the declarativeNetRequest API. They are also planning to increase the ruleset size, which was 30k earlier.

Users are, however, not convinced by this clarification. One user commented on Hacker News, “Keep in mind that their story about performance has been shown to be a complete lie. There is no performance hit from using webRequest like this. This is about removing sophisticated ad blockers in order to defend Google's revenue stream, plain and simple.

Coincidentally, a Chrome 72 upgrade seems to break ad blockers in a way that they can’t see or block analytics anymore if the web page uses a service worker.

https://twitter.com/jviide/status/1096947294920949760

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

Regulate Google, Facebook, and other online platforms to protect journalism, says a UK report

Google announces the general availability of a new API for Google Docs