81–90 of 126 posts
So Ghostery benchmarks and is the fastest? Fine. But Ghostery does not belong in that test at all. Of course it can be faster. It misses a lot of the most important features! Like custom lists. Totally an ad.
Faster still is DNS-based, network-wide blocking with pi hole.
So Ghostery benchmarks and is the fastest? Fine. But Ghostery does not belong in that test at all. Of course it can be faster. It misses a lot of the most important features! Like custom lists. Totally an ad.
I wouldn't really call promoting their own product on their own webpage an ad.
You know what slows down browsing the internet? Ads.
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)?
This doesn't just knock the power of your adblocker down from Type-0 to Type-4 of the chomsky hierarchy, it also limits the inputs it can act on.
As an example, if I wanted an adblocker that looks at the DOM or javascript state of a page before allowing a request to load an iframe this would have to happen asynchronously since it means communicating with the page context. You can't do this declarative style.
Or if one wanted to implement a "click to play" style tool for iframes one would have to hold the request indefinitely until the user approves. This probably isn't a good idea for technical reasons, but at least it is a possibility with current APIs.
> 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…
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…
Maybe these results are only applicable to the desktop version of Brave?
So Ghostery benchmarks and is the fastest? Fine. But Ghostery does not belong in that test at all. Of course it can be faster. It misses a lot of the most important features! Like custom lists. Totally an ad.
Scroll to the footer and you'll see that this is Ghostery's website. I wouldn't really call promoting their own product on their own webpage an ad.