Adblockers Performance Study

> This work was motivated by one of the claims formulated in the Manifest V3 proposal of the Chromium project: "the extension then performs arbitrary (and potentially very slow) JavaScript", talking about content-blockers' ability to process all network requests. From the measurements, we do not think this claim holds, as all popular content-blockers are already very efficient and should not incur any noticeable slow-down for users.

There's a few issues with the conclusion here. First, they article measures and discusses only the time required to block a single request. Modern web pages are issuing many, many more requests than that, like the 35 that this page issues. At median timings, that would put the DuckDuckGo blocker at almost 300ms, well within what humans can notice.

The second is that this API is not used solely by the popular content blocking extensions, but by a variety of other extensions. The Chome team's performance concerns likely stem from the fact that a user won't be able to differentiate the browser slowing down and an errant extension slowing down the network requests, and there are examples of extensions that use this API to issue additional network requests or do slow things down. If you cherry-pick the good citizens of this API to show that performance isn't a problem in general, you're not showing that performance can't or shouldn't be the reason, just that it isn't the reason for the fast good citizens. What this data could be used to argue is that imposing strict deadlines on the execution time of these extensions would allow the content blockers that the community cares about to continue to function as they do today while also placing a performance cap on bad extensions.

I'm actually surprised that Brave's Adblocker was not the fastest, considering that they have native (as in, their own browser) support.

> This work was motivated by one of the claims formulated in the Manifest V3 proposal of the Chromium project: "the extension then performs arbitrary (and potentially very slow) JavaScript", talking about content-blockers' ability to process all network requests. From the measurements, we do not think this claim holds, as all popular content-blockers are already very efficient and should not incur any noticeable slow-down for users. Moreover, the efficiency of content-blockers is continuously improving, either thanks to more innovative approaches or using technologies like WebAssembly to reach native performance.

I don't think it's valid to debunk this claim without testing the speed of manifest/content blocker list-based blocking.

Thanks for the replay. Disclaimer, I worked on this study.

> There's a few issues with the conclusion here. First, they article measures and discusses only the time required to block a single request. Modern web pages are issuing many, many more requests than that, like the 35 that this page issues. At median timings, that would put the DuckDuckGo blocker at almost 300ms, well within what humans can notice.

That is true, but on the other hand the DuckDuckGo blocker is the exception here and they could likely improve this performance if it becomes their focus (one way would be to use one of the faster open-source alternatives). If you consider uBlock Origin, Adblock Plus or Ghostery, we see that even blocking 100 requests would not take much time (probably around 1 ms with Ghostery).

> The second is that this API is not used solely by the popular content blocking extensions, but by a variety of other extensions. The Chome team's performance concerns likely stem from the fact that a user won't be able to differentiate the browser slowing down and an errant extension slowing down the network requests, and there are examples of extensions that use this API to issue additional network requests or do slow things down. If you cherry-pick the good citizens of this API to show that performance isn't a problem in general, you're not showing that performance can't or shouldn't be the reason, just that it isn't the reason for the fast good citizens. What this data could be used to argue is that imposing strict deadlines on the execution time of these extensions would allow the content blockers that the community cares about to continue to function as they do today while also placing a performance cap on bad extensions.

There are indeed examples of extensions doing bad things: collecting private data, etc. But we are talking about diminishing the potential privacy protection of all users to prevent some abuse. On the other hand, the manifest v3 will not prevent extensions from being slow, or doing bad things. Extensions will still be able to use content-scripts, inject arbitrary content in pages or send any private data home. WebRequest listeners will also still be accessible (only not in blocking mode) which can allow any data collection.

So yes, I think these changes could in theory prevent some cases of abuse, but I strongly believe that they will overall weaken the privacy protection of users and that this is not an acceptable trade-offs.

> congrats on being faster than uBlock Origin

I'd like to see a comparison against the WebAssembly build of uBlock Origin though. uBlock Origin uses WebAssembly in Firefox to speed up some functions. I'm not sure if Chrome allows add-ons to use WebAssembly yet.