Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Adblockers Performance Study

whotracks.me

Post reply on HN
Print view View original

21–30 of 126 posts

Re: Adblockers Performance Study

#21

Post by saagarjha »

pythux wrote: post #18
mirashii wrote: post #12

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

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

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

I can choose to not install extensions that do these things, while using ones that only have a manifest list…

Re: Adblockers Performance Study

#22

Post by dasuisa »

mirashii wrote: post #12

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

As you suggest, there are many ways to punish the bad citizens (slow or malicious extensions) without harming the good ones, which is what manifest v3 will do. You can solve with UX (e.g. showing that an extension is slowing down a page), or imposing strict guidelines on extensions for webrequest API times. Google is already quite strict on many aspects for extensions (e.g. obfuscated code was forbidden recently), so I don't see why they cannot be strict also with performance.

Re: Adblockers Performance Study

#23

Post by pythux »

saagarjha wrote: post #16

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

Hey, disclaimer: I worked on this study.

I would love to hear your thoughts about this. From our point of view, the argument is not that the native content blocker is slow or fast but instead that it's not an acceptable trade-off, for different reasons (see link below). We also show that some of the most popular content-blockers are more than fast enough in this regard. I would love Chrome to propose this declarative API as an addition to the current WebRequest APIs and incentivize developers to use it when it makes sense. But replacing the current WebRequest's blocking capability with this would prevent extensions from protecting users as efficiently as today.

I wrote a bit more about other reasons I think the declarative API as only blocking capability of the browser is not a good thing IMO: https://news.ycombinator.com/item?id=19175265

Re: Adblockers Performance Study

#24

Post by StreamBright »

thetinguy wrote: post #5
StreamBright wrote: post #3

Also, how about blocking on the DNS level? Why does this article concerned with in browser ad blocking only? I bet it is much less resource utilisation if you do it in lower layers.

DNS adblocking sucks because it takes too long to turn off when a website breaks because of ads.

On contrary, I do not want to use any website that breaks because of ads.

Re: Adblockers Performance Study

#25

Post by gpm »

magicalhippo wrote: post #6

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…

> Users need to have greater control over the data their extensions can access.

Ok, so then why

> In particular, there are currently no planned changes to the observational capabilities of webRequest

That's before the fact that you consider that webextensions can run arbitrary code on the page and extract whatever information they want.

Edit: Also

> Increased Ruleset Size: We will raise the rule limit from the draft 30K value. However, an upper limit is still necessary to ensure performance for users.

But, as per the article

> All content-blockers except DuckDuckGo have sub-millisecond median decision time per request.

So that doesn't make any sense as a justification either

Re: Adblockers Performance Study

#26

Post by mirashii »

dasuisa wrote: post #22
mirashii wrote: post #12

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

As you suggest, there are many ways to punish the bad citizens (slow or malicious extensions) without harming the good ones, which is what manifest v3 will do. You can solve with UX (e.g. showing that an extension is slowing down a page), or imposing strict guidelines on extensions for webrequest API times. Google is already quite strict on many aspects for extensions (e.g. obfuscated code was forbidden recently), so…

Right, but again, if that's what you want to argue, this article is not the way to do it. Concluding that the performance claim doesn't hold because the top performers are performant is different than saying something along the lines of "While performance may be an issue in some cases, it clearly does not have to be to achieve this use case we care about, and so we should think about alternative solutions".

Arguing this correctly is extremely important if the community wants to change Google's mind, and the miscellaneous fear-mongering and accusations of bullshit motivations that are flying around this and other threads can be easily dismissed if we aren't more careful about how we conclude analyses like these.

Re: Adblockers Performance Study

#27

Post by dasuisa »

clouddrover wrote: post #20
dasuisa wrote: post #11

Perfect way of showing that Google's performance argument is bullshit: just measure. And congrats on being faster than uBlock Origin, not an easy feat.

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

Ah, that's an interesting point, did not know that it could not use WebAssembly in Chrome yet (https://github.com/WebAssembly/content-security-policy/issue...). Would it be interesting to measure indeed, although the amount of wasm code there seems to be minimal so far.

Re: Adblockers Performance Study

#28

Post by StreamBright »

kkm wrote: post #10
StreamBright wrote: post #3

Also, how about blocking on the DNS level? Why does this article concerned with in browser ad blocking only? I bet it is much less resource utilisation if you do it in lower layers.

- 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 capitalism as a whole.

Re: Adblockers Performance Study

#29

Post by pythux »

saagarjha wrote: post #19
pythux wrote: post #15

Earlier quoted context omitted.

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…

Speaking as a user (and early developer) of Safari's content blockers; I have almost never run into an issue with them. What kind of development do you fear will be stifled by Apple and Google not having incentives to improve the blocking (which I find somewhat strange in the former case, anyways)?

What I'm afraid of is the following:

* The blocking engine operated by either Safari or Chrome is a black-box and independent devs will have a harder time understanding it, tweaking it, improving it, debugging it.

* Chrome devs are now playing nicely and get feedback and propose some improvements to the APIs but there is no warranty this will happen again, or that they will invest time/energy in the future improving this part of the browser.

* It's harder to work with this API than a JavaScript code-base you control.

* Chrome seems a bit better here but for Safari the documentation is pretty poor.

* You also don't get feedback regarding the rules which matched on a page and this makes it harder to debug or give nice insights to users.

That's only a few points from my personal experience but I discussed multiple times with developers of other privacy-enhancing extensions/apps and we shared similar feelings.

Re: Adblockers Performance Study

#30

Post by kkm »

StreamBright wrote: post #24
thetinguy wrote: post #5

Earlier quoted context omitted.

DNS adblocking sucks because it takes too long to turn off when a website breaks because of ads.

On contrary, I do not want to use any website that breaks because of ads.

Yes, that's another way to look at it. But it is not necessarily true for all the users.
Post reply on HN