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.
It's perfectly fine and valid to question the pile of JS code executing in Youtube webpages, but in this specific instance the performance issues are caused by ABP/AdBlock. The issue has been acknowledged by the developers[1]. It affects only the latest version of both blockers, not previous versions, so it makes no sense to keep speculating Google is at the root of that specific issue.
Out of curiosity I investigated these performance issues myself using profiling sessions[2] and the faulty code is definitely in the latest versions of these extensions.
Because it has not been updated to the problematic version, which is 5.17. In fact AdBlock on AMO is still 5.4.2, i.e. 13 versions behind latest official AdBlock version, it was last updated in Feb. 2023.
Website idea: a downdetector-like site that uses reddit's "here now" numbers to give insight into whether something is going on with a certain thing.
edit: Has anyone else not really been affected by the new youtube adblock policy at all? I think I have seen the warning a single time, and I use youtube all the time. I only use ublock origin and privacy badger... on chrome. Maybe that's it.
It was rolled out to me. I saw several warnings that my ad blocker wasn't allowed, and on one day they blocked me from watching videos, except that they didn't block me from watching videos in Incognito Mode.
On all other days, I was free to watch whatever I wanted while logged in. They might complain at me about ad blocking, or not.
On all days, youtube-dl worked fine. (This matters because, contemporaneously with the anti-ad-blocking campaign, YouTube started sometimes reducing my video frame rate to 0 fps. Audio never suffered at all.)
It is not, but it did prompt a discussion with my buddies. What do we do when/if it becomes strict? Solutions are kinda there depending on what you are willing to put up with. FWIW, I started archiving stuff with ydl.
My wife uses YouTube a lot more than I do. I watch occasional tech related videos or stuff that's been sent to me. She uses it for audiobooks, music, some podcasts. She subscribes to a bunch of channels. It's her account that's logged in on the TV. I've never seen a message warning about adblocker use on my account, whereas her account got temporarily disabled. She ended up paying for premium.
> Has anyone else not really been affected by the new youtube adblock policy at all?
not really. firefox + privacy badger + ubo. once a week or so i do get blocked but then i clear cookies, restart firefox and relogin and then it works.
I didn't even notice that my YouTube Premium Lite subscription had been terminated for about a month, YT decided to not offer that type of subscription anymore and I'm not willing to pay more for YT Premium, uBlock Origin is working flawlessly.
I think they are just updating their measures frequently, so not really anything technical. In other words: Youtube is continuously spending a lot of money to put out new patches block the latest circumventions.
Not sure it’s a lot of money. Probably just an algorithm to generate variations of the anti Adblock code. At most, polymorphic code inspired by malware.
I actually wonder what is the balance between maybe a small team of software engineers finding way to block adblock vs generate revenue for periods when they are successful.
In the end it really is question that when they manage to block adblock do they make more money than they spend in effort.
This effort is confined to YouTube, but the return of someone uninstalling an ad blocker (the user's response could be more targeted, but some will fully uninstall) reaches Google more broadly.
It isn’t “nothing else”, cosmetic rules can still be updated independently “over-the-air”. One more approach (a bit “hacky”) is to distribute cosmetic rules inside static rulesets (hide them in a separate “metadata” field).
I personally like the fast track idea as we can use the CWS infra to distribute updates quickly, but this is not the only way.
Differential updates are also possible and if they’re implemented, you can keep a normal release cycle (6 weeks for instance).
> It isn’t “nothing else”, cosmetic rules can still be updated independently “over-the-air”.
It's not just about cosmetic rules, it's also about DNR rules other than block/allow/allowAllRequest: redirect=, removeparam=, csp=, etc.
If the idea is that these DNR rules require non-fast-trackable thorough reviews, but dynamically updating them will bypass those thorough reviews, than I am at a lost to understand the logic of treating them as requiring thorough review.
If these DNR rules are considered potentially harmful thus requiring thorough reviews, why would they be allowed to be downloaded from a remote server and dynamically created in the first place?
There is also the content scripts-based filters, which is something that change every day. This is where we diverge, I chose to go fully declarative because this way these content scripts are injected reliably in a timely manner by the MV3 API.
This is not the case when injecting in a event-driven manner since the extension's service worker may need to wake up, fully restore its current state, then by the time it's ready to inject the content scripts programmatically, it might be too late as the target webpage has already started to load.
The “safe rules” concept is a little strange indeed, not very consistent.
I actually agree that for an MV3 ad blocker I’d better have a fully declarative default (emphasis on default), but I’d like to provide an option to grant more permissions and allow more rules. I’ll wait until declarative cosmetic rules become a thing before going this way though.
What I don’t like about your way is that it’s very difficult to use the MV3 version for filters development, filter list authors will have to re-build the extension every time they make any change to the underlying filters.
Maybe this is not a big problem though, we’ll only see it when MV3 becomes the only option and there will be more issue reports from its users.
> If the idea is that these DNR rules require non-fast-trackable thorough reviews, but dynamically updating them will bypass those thorough reviews, than I am at a lost to understand the logic of treating them as requiring thorough review.
While they solve similar problems, these are different systems with different constraints.
* In order to allow something through the review process without close examination, you need to be sure it will not compromise end users. The block, allow, and allowAllRequests actions are known to present minimal risk to user's web browsing activities. The same cannot be said for redirecting requests or modifying a request's headers.
* Dynamic rule registration logic can be statically analyzed for risk assessment purposes. For example, say you're looking at two extensions that both have dynamic rules. Extension A only dynamically register block rules based on remote configuration. Extension B has <all_urls> and passed an arbitrary JSON object to the updateDynamicRules call. Personally, I'd be very concerned about what Extension B could do at the developer's behest, whether intentionally or if the dev's servers are compromised. IMO Extension B may even cross the line on what store policy permits.
* Expectations for extension's static content are different from an extension's dynamic operations. If an extension has code that explicitly does something nefarious and that passes review, the review process will be raked over the coals by commentators. If an extension's static contents are benign but a developer makes it do something nefarious at runtime, there is more understanding that this behavior may not have been visible to reviewers during the review process.
I'm sure there are more differences worth mentioning, but I need to run.
As a final parting thought, if safe rules and fast track review were already implemented and dynamic rules were being proposed today, I expect we'd be having conversations about whether or not devs should be able to register unsafe dynamic rules. I think there's a realistic possibility that we wouldn't allow it. Or if we did, that this capability would be gated by a new permission with a warning.
For an extension to be entirely declarative, it must package all the scripts to inject anywhere, the scripting.registerContentScript API doesn't allow injecting code as string[1], the content scripts must be part of the package.[2]
There is userScripts API which allows injecting code as string, but it's impractical as in Chromium-based browsers this requires extra steps by the user to enable the API.[3] In Firefox, the documentation for this API has the following note[4]:
> When using Manifest V3 or higher, use scripting.registerContentScripts() to register scripts
> uBlock to intercept http requests before rendering the web page. And from my understanding this has always been supported in Firefox, but never in Chrome.
The webRequest API does allow to intercept and cancel HTTP requests, it has been part of Chrome extensions API since 2011.
> I get a 3-5 sec lag on launch [0] as it prepares the browser to block ads.
uBO is typically ready in a fraction of second, so "3-5 sec" is not normal. In Firefox all extensions sit in the same process, so it's possible another extension is preventing uBO to be ready in a timely manner, this has happened[1].
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:
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.
* * *
[1] https://github.com/gorhill/uBlock/wiki/Advanced-settings#ben...