uBOL-home VS webextensions

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

> 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 this assertion. 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.

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

* * *

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

[2] https://github.com/uBlockOrigin/uBOL-home/tree/main/chromium...

[3] https://developer.chrome.com/docs/extensions/reference/userS... ("Availability Pending")

[4] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

AIUI it's because declarativeNetRequests requires the filters to be specified statically, see https://developer.chrome.com/docs/extensions/reference/decla...

Also note that the site you linked is for UBlock, which is a different extension from UBlock Origin. The UBlock Origin Lite (UBlock Origin for MV3) page has an explanation: https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-as...

You can also use a declarative adblocker like uBlock Origin Lite [1], which only provides the browser with a list of elements to filter, but doesn't have any permissions to read content or perform requests. Or simply use your hosts file to apply OS-wide filtering with no browser add-ons needed: https://github.com/StevenBlack/hosts

Be aware that if you use these "passive" blocking methods, there are some sites like YouTube where you will see ads, because in these cases it's necessary to actually manipulate page content to hide them. What you can do is use a traditional adblocker but enable it only for these few sites where the declarative approach is not enough, take a look at [2] for more details.

[1] https://github.com/uBlockOrigin/uBOL-home

[2] https://seirdy.one/posts/2022/06/04/layered-content-blocking...

> The author's description even seems to praise Manifest v3 in the same way Google PR did.

No, it simply declares the goal of that add-on: to fully comply with declarative ways of MV3 and its limitations, and no uBO extended features that need workarounds to be implemented.

He's more strict to Lite than full version:

- https://github.com/uBlockOrigin/uBOL-home/issues/17

Obviously a project like this has already been offered 7-figure deals already: https://github.com/uBlockOrigin/uBOL-issues/issues/44

And he declined all.

I've edited my comment to also include a link to the Chrome docs, but that FAQ entry also has the link to an issue in the webextensions repository indicating it's a limitation of MV3: https://github.com/w3c/webextensions/issues/112

Google outlawing dynamic code in Web Extensions/mv3 is a travesty of high order. There's no place I want to be able to be more alive than my agents. Yet my agents must all be dead. For shame, ye villains.

https://github.com/w3c/webextensions/issues/139

This post definitely was quite a technical explanation. The opening framing, to me, means the world.

The other big change of mv3 that gets no coverage but which is dear to me is that mv3 outlaws any kind of dynamic code. The whole app has to be statically defined. This makes it much easier to know what's running, since an extension can no longer go pull in extra code, but it greatly reduces what you can do as an extension too. Extensions have to have all behaviors predefined. I can't dial home & load my behaviors. Here's the issue, https://github.com/w3c/webextensions/issues/139

For a while it meant that userscripts didn't have any way to run. So Google introduced a new API for user scripting. But those extensions only run in "developer" mode. I'm guessing that means when devtools are open?

I agree a lot with your premise. It sure seems like Google is targeting everyone with these changes, but that better real affordances & escape hatches need to be builtin to not maim the lives of power users. It took a long long time to come up with a userscript solution, and it seems like an awful doesnt-work-for-me workaround (I use userscripts not to dev but to modify everyday experiences). Chrome just hasn't been taking their obligation to user agency seriously.

> the extension APIs are standardised enough that this is actually possible a lot of the time

A bit off topic, but as a co-chair of the WebExtensions Community Group[1] (WECG) I'm a bit touchy about the calling WebExtensions "standardized." A few years back the Browser Extensions Community Group[2] created a spec for WebExtensions, but it never reached a state that we'd normally refer to as a web standard. (Technically W3C community groups can only produce "Reports" and these documents are not on the standards track.[3])

FWIW, I'm very bullish about specifying and (hopefully) standardizing the WebExtensions platform. I'm especially excited about having a good chunk of dedicated time to sit with browser folks at TPAC 2023[4] and try to work out some open questions about where we're going and how we're going to get there.

[1]: https://github.com/w3c/webextensions/

While I was trying to find out what Firefox's limits are I came across this interesting issue on the W3C's webextensions repo: https://github.com/w3c/webextensions/issues/319

4 days ago the Chromium developers proposed upping the limit for certain types of declarativeNetRequest rules based on data AdGuard provided on real world rule lists.

Manifest v3 is used for Chrome's extensions system. The proposal appears to limit what extensions have access to, and what they can do in Chrome. It is proposed as a W3C standard by Google. It is being tracked at the W3C at https://github.com/w3c/webextensions/issues/44.

Google is not even close to finishing MV3: "On the userScripts API, the proposal has been merged into the WECG but the engineering work has not started yet." https://github.com/w3c/webextensions/blob/f8f430f1904c2a6fa8...

MV2 is sticking around until at least 2024.

Some, but not all, limitations are highlighted in this thread: https://github.com/w3c/webextensions/issues/72