webextensions VS uBlock-issues

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

There is an open issue for this: https://github.com/uBlockOrigin/uBlock-issues/issues/2786 uBO should report such filter as en error in Firefox, so that is the thing to fix.

This would be the price of one of the four CDNs (6000$ per month): https://github.com/uBlockOrigin/uBlock-issues/discussions/2958

opened a bug report https://github.com/uBlockOrigin/uBlock-issues/issues/3003

Current estimated cost for just ONE of uBO's CDNs: HERE. This is with other lists updating every few days. uBO's not a company, it's a volunteer project using free services, which have limits that we cannot cross.

The extension with the best success rate seems to be **uBlock Origin**. It is a community driven project with a team of volunteers, you can review the source code [here](https://github.com/gorhill/uBlock). You will need to update your filter lists regularly, this because Youtube changes detection methods daily. Here is how you do that:

Definitely a much-needed area for development. However, having gone down the browser extension rabbit hole, I've largely shifted my focus to user scripts. Granted, there will always be a need for specialized browser extensions like ad blockers (uBlock[1]), keyboard shortcuts (Vimium-C[2]), and password managers (Bitwarden[3]).

That said, I find user scripts superior for most tasks, despite some lacking UI niceties. They are easier to share, use, and crucially, audit—be it in terms of scope, permissions, or code updates. Plus if Manifest V3 is any indicator, the future for browser extensions looks bleak. While I don't agree with this direction, it's probably for the best for the majority of users, like my mom.

Your effort is commendable; however, should you find yourself looking for a viable pivot in the future, I believe the user script space is primed for innovation and could offer a good alternative.

[1] https://github.com/gorhill/uBlock

const defineProperty = function(chain, cValue, middleware = undefined) { let aborted = false; const mustAbort = function(v) { if ( aborted ) { return true; } aborted = (v !== undefined && v !== null) && (cValue !== undefined && cValue !== null) && (typeof v !== typeof cValue); return aborted; }; // https://github.com/uBlockOrigin/uBlock-issues/issues/156 // Support multiple trappers for the same property. // // trapProp is used to trap a single property within an object. const trapProp = function(owner, prop, configurable, handler) { if ( handler.init(owner[prop]) === false ) { return; } const odesc = Object.getOwnPropertyDescriptor(owner, prop); let prevGetter, prevSetter; if ( odesc instanceof Object ) { if ( odesc.configurable === false ) { return; } if ( odesc.get instanceof Function ) { prevGetter = odesc.get; } if ( odesc.set instanceof Function ) { prevSetter = odesc.set; } } Object.defineProperty(owner, prop, { configurable, //When a property is accessed (get), the custom getter function is called. get() { if ( prevGetter !== undefined ) { prevGetter(); } return handler.getter(); // cValue }, // When a property is modified (set), the custom setter function is called. set(a) { if ( prevSetter !== undefined ) { prevSetter(a); } handler.setter(a); } }); }; // trapChain is used to recursively trap properties along a chain of properties (e.g., object1.object2.property). const trapChain = function(owner, chain) { const pos = chain.indexOf('.'); if ( pos === -1 ) { trapProp(owner, chain, true, { v: undefined, init: function(v) { if ( mustAbort(v) ) { return false; } this.v = v; return true; }, getter: function() { return cValue; }, setter: function(a) { // Middleware is called when a property is set, allowing additional processing or validation of the new value. if (middleware instanceof Function) { cValue = a; middleware(a); } else { if ( mustAbort(a) === false ) { return; } cValue = a; } } }); return; } const prop = chain.slice(0, pos); const v = owner[prop]; chain = chain.slice(pos + 1); if ( v instanceof Object || typeof v === 'object' && v !== null ) { trapChain(v, chain); return; } trapProp(owner, prop, true, { v: undefined, init: function(v) { this.v = v; return true; }, getter: function() { return this.v; }, setter: function(a) { this.v = a; if ( a instanceof Object ) { trapChain(a, chain); } } }); }; trapChain(window, chain); }

Maybe https://github.com/uBlockOrigin/uBlock-issues/issues/2725 ?