Adblockers Performance Study

> Continuing to push the narrative that the performance concerns are bullshit

There are two ways to interpret Google's claims about performance:

A) Content blocking in general is impossible to do quickly without a declarative API.

B) The current API gives bad extensions too much power to slow down pages.

We already know that argument B is wrong, because the changes Chrome is proposing don't prevent extensions from slowing down the page. If Chrome was completely, 100% deprecating the old API, I think B would be a much, much stronger claim. But they're not.

So that leaves argument A, which is exactly what this article attacks. It is possible to build adblockers with the current APIs that are good enough that performance doesn't matter.

Now, if the Chrome team wants to argue that extensions have too much power and malicious actors can do bad things, that's a legitimate claim to make that I honestly kind of agree with. But that's so clearly not what the point of these changes are, because a set of changes that were focused on that would look very different from what we've gotten. It's the same reason why I don't take Google's privacy claims seriously for the manifest -- because they haven't actually deprecated any of the worst features that allow people to spy on me.

If someone claims that they need to buy a new car to help save the environment, and then they show you an ad for a pickup truck, I think it's reasonably safe to assume the original claim was just an excuse.

> most blocking software working on the network layer use DNS, which still works just fine and will likely continue to work forever.

Don't say that twice. Have you heard about DNS over HTTPS? I'm using XPrivacy on Android and have noticed that applications that use Android System WebView (based on Chrome) started making requests to 8.8.8.8, 1.1.1.1 and other public DNS services. It's still possible to block domains via hosts file, but I bet it's a matter of time when Google decides it's "in our interest" to start using their DNS instead of ISP's one.

> Some things are very wonky with the experiment:

Thank you for taking the time to read this study. We do not think we claimed anything that was false in this study (although the scope might not be as wide as some would expect or desire); this is not a reason to be dismissive. We have ourselves a lot of respect for the work done at Brave.

> Brave is intentionally slow on parsing and do as much work there because it doesn't parse from client code, it only use already parsed lists from memory.

That was indeed one of the things measured, but not the most important one. In fact we explicitly say that this is a one time operation and does not necessarily matter, especially if as you suggest you can perform this work backend-side and ship the serialized version to clients. What is more interesting is the time it takes for matching requests.

> "The memory usage of Brave could not be evaluated using the devtools and thus is not included in this section." That doesn't make sense, I wonder if it's maybe using a very old version based on the old muon code base? If you can get the memory from Chrome you can get it from Brave.

If we got this thing wrong we would be very happy to update the results with the correct measurements. The version we used was the latest version from `master` on the following repository: https://github.com/brave/ad-block

> No information was given about versions that were tested.

This is indeed unfortunate and we will be correcting this. The measurements were performed last week with the latest version of each projects but we should definitely indicate the exact version used.

> Total parsed rules is too small.

Too small for what exactly? Easylist is one of the most popular lists and it's pretty common to use it as a base-line for comparison. It is trivial to re-run the experiment with different lists given that all the code is open-source.

Benchmarking is always a hard problem - no such thing as spherical chickens in a vacuum. That said we'd love to at least standardize the setup for other people running the benchmarks; that is why we opened all the code and data, as a starting point.

For the study, measurements were run with one of our personal laptops (an X1 Carbon from 2016 with an i7 U6600 CPU and 16 GB of Ram, which is indeed a pretty powerful machine). We tried very hard to limit the impact of frequency throttling due to limited thermal dissipation of the device for the long-running benchmarks. In fact, for the measurements we put the laptop outside at 0 degrees Celsius, and we could observe that the CPU temperature did not go beyond 60 degrees (which is pretty low).

Do you have any suggestions on how we could improve this setup? We welcome all contributions.

Transparency in software releases isn't all-or-nothing. The parent comment makes a good point about preferring more transparency (free and open source software) over less transparency (proprietary software) as a consumer.

However, the parent comment is a bit misplaced since Ghostery appears to be released under the Mozilla Public License 2.0.

https://github.com/ghostery/ghostery-extension/blob/master/L...