> My point was that "reduces ad blockers to static filter lists" is not true as it is not a static list of rules.
That's not what we mean by static either. What we mean by static is that extensions lose the ability to dynamically analyze requests and block them using on-the-fly logic.
> Yes, they are. Due to early versions of declarativeNetRequest only having a static list of rules there are a large amount of people who believe this to still be true.
Very obviously that is not what gkbrk meant by "powerful dynamic filters", considering that gkbrk clarified that they were referring to the ability to dynamically modify requests literally one sentence later. Also very obviously that is not what gkbrk meant because gkbrk literally said in the first sentence that they weren't talking about filter list caps.
When you replied to gkbrk saying that dynamic filters were supported you were not correcting misinformation, you were saying that gkbrk was wrong -- and they're not, they're correct -- dynamic filtering of the kind they are talking about is not supported and the lack of that API meaningfully constrains adblockers (a point which, quite frankly, you don't even disagree with given that you are characterizing this as a "tradeoff").
Did you mean to reply to a different person who wasn't present?
> Considering MV3 lets extensions turn every page into a blank document or inject random scripts I don't see how it can be possible for ads to somehow force themselves to be shown to the user.
"Just inject scripts into the webpage" is a wild take from someone who is trying to claim that Manifest V3 improves privacy, security, or performance. Nobody wants addons to be putting all of their functionality into the page itself, there are myriads of problems with that approach. If you're defending Manifest V3 and you're suggesting that addons should just completely destroy the separation between extension code and page code, then... I mean, that's just not a serious suggestion.
It's good that extensions can insert code into pages, that is sometimes necessary and extensions should have that ability. I think uBO full-on uses that ability for some features. But running code that way is not the preferred way to handle functionality or request blocking, and its something that should be done sparingly and carefully.
If the upshot of Manifest V3 in Chrome is to encourage developers to start pushing tons of extension code into the page itself when they could have before kept that code separate -- then that's a failure of Manifest V3; injecting tons of extra scripts into pages that wouldn't otherwise need to be there will make performance, security, and privacy worse for end users.
> The relevant issue in the bug tracker is https://bugs.chromium.org/p/chromium/issues/detail?id=115104... and the engineer working on it does not have enough bandwidth.
So it's not supported. I'm sorry, you want me to pretend that developer concerns have been addressed because there's an open issue where the developer is overworked and does not have the bandwidth to address it? This issue has been open for 3 years! You could not show a better example of the intrinsic problems with Manifest V3 and the intrinsic problems of extension devs needing to ask Chrome devs for permission to innovate on adblockers if you tried.
This is exactly the problem of Manifest V3. There's need for adblockers to be able to innovate, and when that innovation is dependent on Chrome adding specific APIs, then the issues sit open for 3 years. Chrome is proving before V3 even becomes a requirement that they are not capable of keeping pace with adblocker innovation and that this whack-a-mole approach to adding individual capabilities into declarativeNetRequests is unworkable and bad for addons.
If Google can't keep pace with requests during a period when extensions are still able to use V2, then they're not going to magically get better at handling feature requests when every extension is using V3. If Google's approach to addon APIs is to overwork developers and spread them thin between features, it is reasonable to conclude that either Google does not see addon support as a priority worth investing sufficient developer resources into, or that Google's model for browser development is just inherently not capable of handling API requests at a reasonable speed.
---
And I think that's the broader point. This is not a healthy relationship for Chrome to have with extension developers, and Chrome is proving in real time that it doesn't have the resources or ability to support developer requests.
But to address the other specific APIs you bring up:
> This is no longer a problem with declarativeNetRequest since the rules for blocking network requests is part of the browser itself.
I'm sorry, the inability of an extension to load before the browser starts sending requests is a non-issue to you? Sure, you can pull the blocklist out so the static rules still take effect before the extension loads, but that is far from the only issue in having extensions load asynchronously from their pages.
To be fair, you are right that declarativeNetRequest makes this slightly better, but only because prior to declarativeNetRequest Chrome already exhibited this behavior so at least now there's one way to make sure that requests get filtered from browser launch, as limited as it may be. As opposed to Firefox, where this has never been a problem for either MV2 or MV3 extensions, because Firefox doesn't make the wild decision to start loading pages before the user's addons have initialized.
> Some of these are self inflected by the author like only updating rules with store updates
I actually don't think that's the main problem with most of these. Dynamic user rules, fonts, and noscript rules are blocked by rule scoping around top-level document URLs, not because of store updates. uBO Lite does avoid making network requests to update lists, but that is one paragraph out of an entire page describing limitations that make useful features difficult or impossible to build under MV3.
Additionally, if you dig into the actual details of what Gorhill is saying about updating extension lists, you'll find that this is not just about whether you can load list updates, it's also about when it happens and the fact that (as mentioned above) uBO Lite can't guarantee that it will be running when a request is made, and can't guarantee that those rule updates will take effect before the request is sent.
> and, some of these are due to the lack of maturity of MV3
Well, it's a good thing that Google is waiting for MV3 to become mature and it's a good thing that MV2 won't stop working in June, right? /s
> some of these are due to trade offs that are being made ecosystem wide.
Sure, other apps other than adblockers will also be affected. I maintain hobby Firefox extensions that are impossible to ship on Chrome for Manifest V3. Do you expect "we didn't just break adblockers, we broke lots of other addons too" to be an argument that makes anyone more sympathetic to Google?