[danShumway]

> It allows for 30,000 dynamic rules

That is not what we mean by dynamic filters. From https://developer.chrome.com/blog/improvements-to-content-fi...

> However, to support more frequent updates and user-defined rules, extensions can add rules dynamically too, without their developers having to upload a new version of the extension to the Chrome Web Store.

What Chrome is talking about is the ability to specify rules at runtime. What critics of Manifest V3 are talking about is not the ability to dynamically add rules (although that can be an issue), it is the ability to add dynamic rules -- ie rules that analyze and rewrite requests in the style of the blockingWebRequest permission.

It's a little deceptive to claim that the concerns here are outdated and to point to vague terminology that sounds like it's correcting the problem, but on actual inspection turns out to be entirely separate functionality from what the GP was talking about. It's almost like the Chrome team deliberately decided to call these "dynamic rules" so they could claim that Chrome supported them and muddy the issue, even though Chromes "dynamic rules" have nothing to do with support for a blockingWebRequest API. But I don't want to be conspiratorial.

> Giving this ability to extensions can slow down the browser for the user. These ads can still be blocked through other means.

This is the debate; most of the adblocking community disagrees with your assertion. Chrome has been saying this for ages, but saying it doesn't make it true.

uBO maintains a list of some common features that are already not possible to support in Chrome (https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...) and has written about features that are not able to be supported via Chrome's current V3 API (https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-as...). Of particular note are filtering for large media elements (I use this a lot on mobile Firefox, it's great for reducing page size), and top-level filtering of domains/fonts.

Chrome could of course add support for some of this -- Chrome could implement more filter controls for analyzing headers and request sizes, but as far as I know that support hasn't been added yet. And even if that support does eventually get added, this all glosses over the bigger issue that devs have been saying from the beginning, which is that it's ridiculous to make every innovation in adblocking dependent on Chrome explicitly adding new APIs to support each individual use-case. The model that Chrome is moving towards is one where every new kind of filtering metric that devs want to use requires asking Google for permission to use it and waiting for Chrome to implement it.

[charcircuit]

>That is not what we mean by dynamic filters.

My point was that "reduces ad blockers to static filter lists" is not true as it is not a static list of rules.

>What critics of Manifest V3 are talking about is not the ability to dynamically add rules

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. On this site I have encountered many people who make a claim about it being impossible to update rules without an update to the extension through the store.

>It's a little deceptive to claim that the concerns here are outdated and to point to vague terminology that sounds like it's correcting the problem, but on actual inspection turns out to be entirely separate functionality from what the GP was talking about.

Dynamic rules do correct the problem of a static list. The second half of my comment points out that there was a trade off made between functionality and performance which is why "dynamic filters" are no longer possible.

>This is the debate; most of the adblocking community disagrees with this assertion.

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.

>common features that are already not possible to support in Chrome

>CNAME-uncloaking

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.

>Browser launch

This is no longer a problem with declarativeNetRequest since the rules for blocking network requests is part of the browser itself.

>as written about features that are not able to be supported via Chrome's current V3 API

Some of these are self inflected by the author like only updating rules with store updates and, some of these are due to the lack of maturity of MV3, some of these are due to trade offs that are being made ecosystem wide.

[danShumway]

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

[charcircuit]

>That's not what we mean by static either.

What is a static filter list other than a list of filters that does not change?

>When you replied to gkbrk saying that dynamic filters were supported you were not correcting misinformation

I was saying that the filter list was dynamic and not static.

>"Just inject scripts into the webpage" is a wild take

I was pointing out the upper bounds of what was possible and not giving recommendation on how it should be done.

>So it's not supported.

That is right.

>you want me to pretend that developer concerns have been addressed

No, I want people interested in this feature to track the bug or contribute the fix themselves since it is an open source project.

>it is reasonable to conclude that either Google does not see addon support as a priority worth investing sufficient developer resources into

That is correct in my understanding. This means that the open source community needs to dedicate their own resources if they want to accelerate progress here.

>the inability of an extension to load before the browser starts sending requests is a non-issue to you

Assuming no events are dropped then I don't see it as an issue.

>doesn't make the wild decision to start loading pages before the user's addons have initialized.

It doesn't sound that wild if it speeds up launch time by not blocking on third party extensions having to load.

>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

This is not an issue as the extension does not need to be running for the browser to apply the rules. The extension is only needed to update the rules.

>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

Considering that the deadline keeps being pushed back, I think they recognize that it has low maturity.

[gkbrk]

> What is a static filter list other than a list of filters that does not change?

A request is being made. At the time of the request, you go through a list of rules and decide if you're going to block or allow it.

Once the request reaches the filter, you are working with a static list because you cannot make decisions using the content or circumstances of that particular request. You cannot add or remove anything to your list after looking at the request.

A dynamic filter on the other hand could

- Resolve hostnames with DNS to do CNAME uncloaking

- Decode encoded requests so the website cannot send both real data and analytics/tracking data through a single URL. Being able to make dynamic decisions allows the ad blocker to inspect request headers and request bodies.

- Modify responses. The web page could be getting ads from a JSON endpoint with the rest of the page. You can use filterResponseData and change the response dynamically to strip the ads return an empty JSON list for example.

[danShumway]

Exactly. Or in other words:

> It also reduces ad blockers to static filter lists instead of powerful dynamic filters. MV3 makes it impossible for ad-blockers to inspect requests with code and then allow/deny dynamically.

I'm assuming the best here, but it is extremely clear what you meant by a "static filter" in your comment. You meant a filter where it is "impossible for ad-blockers to inspect requests with code and then allow/deny dynamically."

It's a little frustrating to have to pretend that any of this is ambiguous.

[danShumway]

> No, I want people interested in this feature to track the bug or contribute the fix themselves since it is an open source project.

> That is correct in my understanding. This means that the open source community needs to dedicate their own resources if they want to accelerate progress here.

OR... hear me out: we could recognize that Chrome, a browser owned by one of if not the most powerful tech companies in the entire world, does not need charity, and that it's not a community owned project (if it was, MV2 would not be getting deprecated), and that the community has no say in how the project gets updated or maintained and is fact very regularly treated with hostility by the project, and that instead of trying to fix an issue that Google probably isn't even interested in getting help with, we could instead go use and contribute to Open Source browsers that aren't transparently trying to kill adblockers.

This is wild. You went from "MV3 is fine, there's just a lot of misinformation" to "MV3 is trying, but the devs are overworked" to "nobody is allowed to complain about this unless they're giving hecking Google free labor."

Google made a decision to deprecate a working API, developers correctly pointed out that the API hobbles adblockers, Google has not fixed the API but is launching it anyway, and your answer is that the open source community needs to dedicate their own resources. This problem is not our fault, we didn't make it.

How about Google not completely rewrite an API out of the blue if they don't have the internal resources necessary to do so? Is there some hiring freeze on developers, has Google lost the ability to hire and pay people? Google creates a problem, and you're blaming the Open Source community for not fixing Google's problem for them, a problem that exists entirely of Google's own free will, because Google ignored the Open Source community that was desperately trying to stop Google from making the problem.

The Open Source community has a solution to this; don't deprecate blockingWebRequest. Like most community feedback, Google isn't interested in hearing that.

I would suggest that if Open Source developers need to contribute somewhere, they could try contributing to Firefox, a browser that has none of these problems because somehow a company that is so small its entire corporate profits would barely register in Google's spreadsheets is still better at building extension APIs than Google is.

----

> Assuming no events are dropped then I don't see it as an issue.

It's an issue because extensions sometimes like to respond to events when they happen. If the browser stopped allowing synchronous responses to click events and I said, "well as long as they eventually trigger there's no issue" I would be rightly laughed out of the room.

The issue is that a user can update filters and they have no guarantee that the filters will be updated before the requests that they mean to block are fired off. If an adblocking extension does decide to update filter rules on launch, they have no guarantee that the update will take effect before the page loads.

> It doesn't sound that wild if it speeds up launch time by not blocking on third party extensions having to load.

Not loading the extension at all would speed up launch time even more, Google should just get rid of extensions entirely /s

People use extensions as a way to increase security and to build reliable features into the browser. There are many use-cases from tab-control to feature toggles where having tabs and pages load before extensions breaks functionality. It is wild to suggest that breaking functionality in userspace is preferable to adding an extra second to a browser launch.

For many people, adblocking is a security issue. To suggest that the browser should occasionally just send requests anyway before an extension has time to update and apply rules is like suggesting that a desktop should start loading and displaying user settings before it checks the user's login password.

> This is not an issue as the extension does not need to be running for the browser to apply the rules.

See above.

----

> Considering that the deadline keeps being pushed back, I think they recognize that it has low maturity.

This is once again a pretty big shift from "MV3 doesn't stop adblockers" to "MV3 isn't ready yet and they should keep pushing it back." It's also optimistic given that Google has given no indication yet that they're going to push back the June deadline.

But most importantly, it also doesn't change anything about my point -- we are seeing that Google does not have the resources to keep pace with adblocking innovations. That's not going to change. This is not a question of MV3 becoming ready and then everything becoming fine: "ready" is a moving target, and Google is not moving fast enough to keep pace with it.

What these issues demonstrate is that the declarativeNetRequest API is poorly designed -- it is poorly designed because it greatly increases the support requirements from Google to a level where the company is unable to meet them. And when Google is unable to meet those support requirements, user security and privacy suffers as a result.

This is an intrinsic problem that is baked into the design of declarativeNetRequests, and it's not going away even if Google does manage to close a couple of bugs. Because more of these issues are coming every time that adblockers need to innovate. If an API increases support burdens to the point where the dominant browser owned by the most powerful tech company has to come crawling to the Open Source community for help triaging 3-year-old issues, then it's a bad API.

And underlying all of the criticism of MV3 is that idea -- that it is not tenable for extension developers to have to request support for every individual feature that adblockers need. A better API would be a more flexible API that allows extension developers to innovate without asking permission. blockingWebRequest is an imperfect API and it has issues, but it allows extension developers to innovate without filing support tickets for every new feature and then waiting 3 years for a response because the API is flexible enough that extension developers can use it in creative ways that the authors may not have fully anticipated or known about.