Live data from Hacker News

Adblockers Performance Study

whotracks.me

41–50 of 126 posts

Re: Adblockers Performance Study

#41

> 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…

I believe this article does debunk the Google performance claim. It doesn't really matter if the "manifest" system is perfectly fast (exactly 0 seconds); this article shows that the current blockers are fast enough that they are indistinguishable from zero. There is limited room for improvement here (so limited as to be effectively none).

Re: Adblockers Performance Study

#42
post #10

Earlier quoted context omitted.

- As pointed out in the previous comment, with DNS based blocking users often have to choose between convenience and privacy. As an example: Blocking ads on Youtube with DNS blocking is very hard, unless you block youtube* itself. - It does not give you fine grained permission: Like, if you only want to allow a particular third-party on a specific site. While DNS based blocking is fast but at the same time it is also…

Youtube is an interesting example, I use it less and less because of ads but can you block ads in it with anything? The problem for me is that I have several devices that do not run JS (like TV box) and do not use a browser for watching content. For this reason it is probably the only solution to block bad content on the DNS level. I like to pay for what I get (Netflix) and I reject the entire ad based surveillance c…

I pay for YouTube (via a Google music subscription) and never see YouTube ads on any device I'm logged in on.

Re: Adblockers Performance Study

#43
post #42

Earlier quoted context omitted.

Youtube is an interesting example, I use it less and less because of ads but can you block ads in it with anything? The problem for me is that I have several devices that do not run JS (like TV box) and do not use a browser for watching content. For this reason it is probably the only solution to block bad content on the DNS level. I like to pay for what I get (Netflix) and I reject the entire ad based surveillance c…

I pay for YouTube (via a Google music subscription) and never see YouTube ads on any device I'm logged in on.

Nice, is this the YouTube Red subscription?

Re: Adblockers Performance Study

#44
post #42

Earlier quoted context omitted.

Youtube is an interesting example, I use it less and less because of ads but can you block ads in it with anything? The problem for me is that I have several devices that do not run JS (like TV box) and do not use a browser for watching content. For this reason it is probably the only solution to block bad content on the DNS level. I like to pay for what I get (Netflix) and I reject the entire ad based surveillance c…

I pay for YouTube (via a Google music subscription) and never see YouTube ads on any device I'm logged in on.

You pay + they collect all of your data (unless your explicitly disallowed some of it). I think it would be only fair if you pay and there is no data collection (by any means, no 8.8.8.8 forced use etc.)

Re: Adblockers Performance Study

#46
post #45

Worth keeping in mind here is that Ghostery is proprietary, while uBlock is free software. You should never trust proprietary extensions with your data.

Ghostery is open-source for almost an year now, You can check the code and repo: https://github.com/ghostery/ghostery-extension

Re: Adblockers Performance Study

#48
> 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.

Not commenting on if the proposed V3 changes are a good idea or not but aren't the changes not supposed to prevent badly written extensions from slowing everything down?

It might be the case these adblockers are well written but you can't guarantee that for all extensions. If a user doesn't have an obvious way to know it's the fault of an extension then Chrome gets the blame.

By the way, I have a Chrome extension that from its own tab requests many pages from arbitrary domains to examine their content. I need to modify the request headers going out and observe the response headers coming in, but only for requests made from the extension (so it's not impacting other tabs at all). I'm guessing V3 impacts this only if the request header modifications are dynamic and can't be added via the fetch API?

Re: Adblockers Performance Study

#49

why is adblock not included?

Good point and we should certainly have mentioned it. AdBlock is using the same underlying engine that Adblock Plus is developing (adblockpluscore), which means they have the same performance when it comes to matching requests (there could still be differences in the extension itself but that was not measured in the study).

Source: https://github.com/betafish-inc/adblock-releases#intro and https://en.wikipedia.org/wiki/AdBlock

Re: Adblockers Performance Study

#50
post #15

FWIW, Chromium devs have just responded[1] to the massive amount of feedback they got on the mailing list, like [2] and [3]. One of the main pain points raised was the lack of any way to dynamically add rules, as well as the low maximum number of rules allowed (30k). Seems they've decided to support dynamic rule addition, as well as increasing the number of rules, though probably not by orders of magnitude by the sou…

Hey, dislaimer: I worked on this study. Thank you for your comment. To me this reaction from the Chromium devs is missing one of the most fundamental issues. I'm not fundamentally against the declarative API because of technical limitations; I am against it because it is a strong innovation lock. The current extension ecosystem is flexible enough to allow hundreds (maybe thousands) of people to actively work on priva…

I tried to make my comment rather unbiased, but yeah, it's still a step in the wrong direction IMHO.
Post reply on HN