Those "adblock test" sites misinform people, they should never be used as they lead people to make bad decisions regarding their choice of content blockers.[1]
Good read: adblock test sites can be wildly inaccurate (alerting to connections that never made it, given redirect to the local shim resource) and can easily be gamed.
Next up would be looking closer at the pages you frequent. I think many people would be surprised at all the ways web apps screw up these days.
All that said, the browsers, as unfair as it may seem, should do better at handling all of the slop that web app and extension developers put out there. It’s sometimes just a whole lot easier to make the browser more bulletproof than it is to make a bajillion JavaScript/python monkeys conscientious and competent.
An alternate between those two endpoints would be to offer better tooling to enable both users and monkeys to identify things contributing to bad outcomes. I don't just mean devtools, either, I mean "oh, it seems this tab is taking up $foo memory because the background image is a 400MB .mp4 and ..." type thing. They went through all the trouble to put AI in the browser, so ask it :-/
There is no claim of "zero CPU". The claim is that the service worker wakes up only when necessary -- it is designed to be suspended by default from the ground up.
In Optimal and Complete modes, the content scripts will of course execute, without the service worker being unsuspended if no filtering occurs, but perform only the necessary work and bail out ASAP if not needed.
In Basic or "No filtering" modes, no content scripts are injected.
---
Edit: Sorry, I do say "uBOL itself does not consume CPU/memory resources while content blocking is ongoing". When I say "itself" I am referring to the service worker as seen in Chromium's Task Manager. The service worker isn't required for examples when navigating to `example.com` or here at `news.ycombinator.com`. All top content blockers I have looked at do require their service worker to execute, even for merely just switching between tabs. Some even use tricks to prevent their service worker to be suspended at all.
Thank you for the explanation! That makes sense now.
I'm still confused about what level of access is given to the extension and what using the extension means.
Clicking on the extension asks for access to the current website, so I'm assuming that without giving access there or clicking "Always Allow on Every Website..." in the Safari settings, the extension does not have access to the web page contents.
Basic filtering claims to not require permission to read the web page data. But the extension is still used and does content filtering right?
Maybe this is more of a comment on Safaris weird terminology in the permission settings.
I just tested with Firefox and uBlock Origin in the stricter "medium mode" and got a score of 1%. So yeah, I don't think these test pages are that great.
Would you be supportive of an "adblock test page" that literally just reports if the adblocker is working correctly, rather than how good it is? Like maybe an EICAR-like rule that is added to EasyList that matches an element on that page?
When you enable "Developer mode" in the "Extensions" page of your browser, you can open the developer tools for the extension by clicking the "service worker" link, and from there select the "Network" tab, you will be able all the network requests made by the extension from within its service worker.
I just started using uBO Lite on Chrome. Brave is my daily driver and I just can't surf the web without an ad blocker anymore. I resisted it for years.
Thanks gorhill. Yes, this is true! Osprey only sends its stripped-down URLs to the services you turn on. Nothing more. It's as anonymous as it can be without using a VPN, afaik.
It's working fine on Youtube in Optimal mode. If you have still issue, you will have to go through self-diagnosing steps[1] to rule out all the myriad other ways you suffer such issues -- most commonly another extension is interfering negatively.
I randomly browsed the site with Firefox stable and I couldn't see any obvious malfunction. What exactly is not working? Is there a specific webpage where the malfunction can be seen?
No competent content blocker tests "ten thousand regexp matches" for each request URL to match, this is not how it works.
To simplify, and speaking from uBO's perspective, consider that nine distinct tokens can be extracted from the URL in the address bar for the current webpage:
https
news
ycombinator
com
reply
id
41758007
goto
item%3Fid%3D41757178%2341758007
To match such URL against the tens of thousand of filters, there is only a need to lookup filters for these nine tokens, and for most of these tokens there won't be any filters to test, such that in the end for any given URL only a few to no filters will end up being tested, and the majority of these filters are not regex-based, they are just plain string matching.
This is the overall simplified explanation of how it really works, in reality it's a bit more complex because there are a lot of other optimizations on top of this.
There is a built-in benchmark tool in uBO, accessible through the dashboard, _Support_ pane, _More_ button, _SNFE: Benchmark_ button[1].
When running the benchmark against a set of 230,364 URLs, I get an average of 11-12 µs per request to perform a match test against the default filter lists in uBO.
The extension in the Chrome Web Store (CWS) never changed hands. I just reverse-forked a GitHub repo, which was of no consequences to those who installed the extension from the CWS. I was asked to transfer the CWS entry, I refused. This can't be compared to an extension changing hands or going rogue in the CWS.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1985170#c3