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

31–40 of 126 posts

Re: Adblockers Performance Study

#31

Post by pythux »

saagarjha wrote: post #21
pythux wrote: post #18

Earlier quoted context omitted.

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…

I agree with you, and that's why I would like to see this declarative API being an addition to the current WebRequest API. This way there could be extensions using it exclusively and users could decide to pick these if they offer sufficient privacy protection for their taste. On the other hand, you would still have the option of installing more powerful extensions using the dynamic APIs (allowing things which will never be possible with the declarative API).

Re: Adblockers Performance Study

#32

Post by StreamBright »

kkm wrote: post #30
StreamBright wrote: post #24

Earlier quoted context omitted.

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.

I understand, I never implied that it is for all users, I was just mentioning that there are other options than JS ad filtering.

Btw. DNS based filtering works for non tech-savvy users like my parents who would certainly fall for malicious ads which are frequent even on Google. And guess how ransom-wares spread.

https://www.zdnet.com/article/skype-served-up-malware-throug...

Re: Adblockers Performance Study

#33

Post by kkm »

StreamBright wrote: post #28
kkm wrote: 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…

On platforms which supports extensions it's easy to block. For platforms not supporting extensions it is really tricky and afaik, there is no solution that works all the time for YouTube.

With the increasing adoption of DoH it will be interesting to see how DNS based blocking happens for TV Box etc.

I have not checked but was mentioned that YouTube does not show ads while watching videos via chromecast. It will be interesting to check how that happens.

Re: Adblockers Performance Study

#34

Post by pythux »

dasuisa wrote: post #27
clouddrover wrote: post #20

Earlier quoted context omitted.

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

As far as I know WebAssembly in uBlock Origin is currently used for two things:

1. Matching the $domain option using an optimized Trie data-structure

2. Parsing domains using the public suffix list, also based on a Trie data-structure

I would love someone well-acquainted with the uBlock Origin code-base to update the benchmark so that we can compare.

Edit: All the code to create the dataset (as well as the dataset used for the study itself) and to run the benchmark and analyze the results (create the plots, etc.) is available on the repository and should be reasonably easy to run locally.

Re: Adblockers Performance Study

#35

Post by kkm »

dasuisa wrote: post #27
clouddrover wrote: post #20

Earlier quoted context omitted.

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

afaik, in Chrome Web Assembly works fine when used inside Workers.

Re: Adblockers Performance Study

#36

Post by kkm »

StreamBright wrote: post #32
kkm wrote: post #30

Earlier quoted context omitted.

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

I understand, I never implied that it is for all users, I was just mentioning that there are other options than JS ad filtering. Btw. DNS based filtering works for non tech-savvy users like my parents who would certainly fall for malicious ads which are frequent even on Google. And guess how ransom-wares spread. https://www.zdnet.com/article/skype-served-up-malware-throug...

Yes, I think there are certain domains specially spyware, malware that need to be blocked altogether and DNS blocking is the most optimal way for that, specially considering the wide adoption of IoT, where extensions cannot run.

Re: Adblockers Performance Study

#37

Post by mirashii »

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.

> Perfect way of showing that Google's performance argument is bullshit: just measure.

I want to repeat here that this _does not_ show that the performance argument is bullshit. What we can say that it shows is that existing content blockers whose functionality the community is concerned about losing are largely performant enough that performance isn't a concern for that subset of extensions.

We can in turn conclude that there may be other ways of solving the general performance concern that the existing API poses by other clever means, such as limiting execution time and disabling extensions that violate those deadlines, or UX changes that allow the user to more readily distinguish which extensions are causing performance issues.

Continuing to push the narrative that the performance concerns are bullshit and a pretext for disabling ad-blockers is hurting the cause of allowing the existing APIs to continue to exist.

Re: Adblockers Performance Study

#39

Post by gorhill »

pythux wrote: post #34
dasuisa wrote: post #27

Earlier quoted context omitted.

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.

As far as I know WebAssembly in uBlock Origin is currently used for two things: 1. Matching the $domain option using an optimized Trie data-structure 2. Parsing domains using the public suffix list, also based on a Trie data-structure I would love someone well-acquainted with the uBlock Origin code-base to update the benchmark so that we can compare. Edit: All the code to create the dataset (as well as the dataset us…

The same code used to match the `domain=` option is also used to match all filters which are essentially just a plain hostname, i.e. `||example.com^` -- which is a majority of filters found in filter lists.
Post reply on HN