The current situation with MV2 is that all extensions have the capability of running dynamic code, in ways that are not obvious to the reviewers, extension stores and users. It is desirable to reduce the set of extensions capable of dynamic code set to a manageable size - in order to have any constructive conversation here, it's necessary to acknowledge this. Some kinds of dynamic code execution can be addressed by new features (like serializable functions in the scripting.executeScript API) or existing ones (sandboxed extension pages), but there are clearly extensions that cannot function without support for dynamic code such as user script managers. Although phrased a bit bluntly, your criticism about the lack of APIs to support dynamic code for specific cases is valid.

User script managers are the most obvious example of extensions that need dynamic code. Are there other extensions?

Side note: even if dynamic code were to be blocked entirely, it's still possible to have a dynamic code execution engine implemented in JS. A malicious one can be very simple, but a full-fledged JS execution engine would have numerous issues (e.g. performance, code complexity, extension store policy compliance). I am not recommending this approach, but mention it to show that preventing all extensions from running dynamic code is not a fully effective way of blocking malicious dynamic code.

Side note: even if dynamic code were to be blocked entirely, it's still possible to have a dynamic code execution engine implemented in JS.

I'd mentioned running something like evaljs in a HN thread & @dotproto said,

While it's possible to build an interpreter in JS, doing so in an extension is an unambiguous violation of the Chrome Web Store Developer Program Policy.

I find it utterly draconian that we're completely eliminating vast vast vast amounts of possibility for the convenience of a couple big companys who run extension stores. I'm sorry it's such a pain & a bother running a place people download other people's code from. That's what we're talking about, that's what "managable size" that you want acknowledged means. But there is so much being lost by this change.

I'd always intended to write some semantic web extensions that let me upload new scripts & behaviors from a centralized site. There was going to be a centralized Yahoo Pipes like system, that my various browsers would then pull down & run as I browse. I think there's a million billion outlets of creativity that folks get up to by having dynamic code allowed in extensions; I'm sorry I don't have a better long list off the top of my head, but I feel completely devestated that there'd be a proposal to wipe out the most free & liberal & exciting form of user-agency the web has. For convenience of store moderators.

I want to add two points here;

One is that yes, a webextension standard should be welcoming to any and all types of extensions, even ones certain stores may deem unfit for their policies, this is about standardising existing extensions, after all.

Second, to please both sides of the fence, I'm recommending for a "dynamic execution" permission to be added to extensions, which enables things such as this, in a similar vein as CSP, stores and browsers could then use this information to appropriately reject or inform users.

I agree that under no circumstances this should get "outlawed", the only thing you're doing then is creating a "standard", a "law book", so to say, that denies a sizeable portion of the subject it's supposed to be addressing "equally", a standard that describes only a subset of the ecosystem it's addressing.

As a consequence, that standard will not be picked up, or rejected, by those who are supposed to be using it, as it's simply not convenient to use a standard that doesn't work with half of the stuff you're using. So many W3C standards feel neglected, denied, or forgotten, please don't make this another one of those.

User script managers are the most obvious example of extensions that need dynamic code. Are there other extensions?

Our extension AutoControl is not a user script manager, but does allow the user to write their own scripts in order to extend the extension's functionality.
In addition to the usual content scripts, our users can also create background scripts, which run in a sandboxed iframe.
Even if MV3 allowed dynamic code, which apparently Google plans to allow before the MV2 end-of-life, our extension will still lose the capability of background scripts because MV3 no longer has a background page in which to create a sandboxed iframe.

Whatever solution is found to cover the legitimate and useful need of dynamic code execution, it must include the possibility of sandboxed background scripts as well in order to be a complete solution.

Second, to please both sides of the fence, I'm recommending for a "dynamic execution" permission to be added to extensions, which enables things such as this, in a similar vein as CSP, stores and browsers could then use this information to appropriately reject or inform users.

I like this idea a lot, the idea of extensions being able to ask for different powers/permissions.

Second, to please both sides of the fence, I'm recommending for a "dynamic execution" permission to be added to extensions, which enables things such as this, in a similar vein as CSP, stores and browsers could then use this information to appropriately reject or inform users.

I agree.
The extension stores may display a big scary warning when installing an extension with such a permission. It will defer the responsibility to the user installing the extension.

Perhaps we could just go back to letting users sideload extensions into Chrome by default, and treating grown adults as reasonably-intelligent people who are generally capable of judging reputation and estimating risks. For those sideloaded extensions, Google could communicate these risks very explicitly (similar to how they do for sideloading on Android, which Google very strangely and inconsistently seems to have no problem with). Perhaps each sideloaded extension could simply have a prominent warning upon installation ("just like almost all of the websites you navigate to in your web browser, Google cannot vouch for the safety of this extension"). And of course for enterprise deployments, admins could simply disable this sideloading potential if they prefer whatever "vetting" the CWS is capable of.

Individuals always have taken and always will take risks when installing software. We all fundamentally judge the reputation of software we can't categorically say we know is "safe". When I started up Chrome today, I didn't know for certain that the latest update didn't have any malicious code (or new zero-day attack vectors for malicious third-party code). When I post on Facebook (or even here on GitHub!), I can't tell you for certain that my data isn't being used for nefarious purposes in one way or another. As far as you and I know, GitHub is a "black box"; When I provide it my SSH/GPG keys, for all I know, these could be sent directly in plain text to some greasy guy eating Cheetos and selling this data to hackers. Perhaps it's sent to a drunk NSA agent who ends up leaking it carelessly. Why do I choose to participate in these systems I don't understand? Trust. As a user, I trust their reputation. Allow users to decide whether to trust the reputations of individual extension developers. Give them as much relevant information as they need to make their own informed decisions. Let users implicitly trust "Cuyler Stuwe" based on their own judgment, the same way they implicitly trust Microsoft, Google, and Apple despite not seeing any hard proof that they're actually "trustworthy".

Problem solved. Google would be now no longer trying to perform the impossible task of trying to guarantee that all software is safe. It would no longer need to play the metaphorical role of the "helicopter mom" who stops their kids from being able to do anything at all for fear of them getting hurt.

This shift toward locking software down to the extent that it essentially can't do anything is starting to grow tiresome. Are we ready yet for the pendulum to swing the other way? It's pretty pointless to have a "safe" system that can't really do much. Reminds me of that popular quote: "Ships in harbor are safe, but that's not what ships are built for." The balance of features and security needs to prefer features, as features are the fundamental purpose justifying the existence of software. You definitely don't want to go wild with risks or recklessly ship unsafe defects, but if your safety measures mean inherently being unable to do what the user needs and/or expects to be able to do, then the system cannot be anything but a failure.

It seems just a little ridiculous and odd that it's degrees of significance easier for a bad actor to distribute an executable virus (which people can accidentally download and run from any website in 2 clicks) than for a benevolent actor to create and publish a useful browser extension.

Anyway, I'll get off my soapbox. I don't think this thread is going to make any meaningful impact on anything, since Google has taken a hard stance on this, and Google essentially owns this extensions spec. Nobody outside of Google really has any meaningful sway, since Chrome currently owns nearly all of the market share; Google sets the rules, other people nitpick minor details, and everyone pretends that everyone had a meaningful say.

Maybe when people start to crave more features in web browsers, MV5 will come along and bring functionality back along with it. My rant here might then seem prophetic. We'll see.

User script managers are the most obvious example of extensions that need dynamic code. Are there other extensions?

Tons.

Lots of configurable platforms for collecting data need this sort of behavior in order to adapt effectively and within reasonable time to site changes.

Userscripts are just the most generic implementation of a myriad of more specific solutions

Many extensions with proven market demand can be described as:

"Essentially userscripts, except specifically tailored by our platform to solve some specific problem".

These types of extensions must fundamentally receive essentially-arbitrary code payloads at arbitrary times from a server and/or the user, so that new issues can be resolved as they appear.

Arbitrary code execution can also be a fairly effective part in a strategy for preventing unlicensed use of a tool. The use of arbitrary code in licensing can make it more difficult logistically for people to distribute "cracked" versions of extensions.

Finally: It makes little sense to poke an arbitrary hole just specifically for userscripts but not for other forms of extensions. If you do, then people will just flock to userscripts, since you'll be able to do more with them than you can do with extensions.

I'd like to encourage constructive critcisim over outright rants. The topic of this topic here is the predicted loss of functionality if the extension platform were to head in the direction of Google's current state of its MV3 implementation, in the context of dynamic code execution.

Change is more likely to be achieved with feasible thoughts and ideas that restore the functionality and support the stated goals (see the initial replies here).

"Change is more likely to be achieved with feasible thoughts and ideas that restore the functionality and support the stated goals (see the initial replies here)."

I have little faith that there will be any meaningful improvement in this for the foreseeable future. All indications I've seen across all publicly-visible discussion channels and documentation regarding this issue point to a very stubborn hardline stance on this issue.

The problem here can be summarized succinctly in three points:

1. Third-party devs and individual end-users want one thing, while Google wants another.
2. It does not seem that Google is really receptive to even entertaining a discussion.
3. It seems that other browser implementors are afraid of irrelevance if they don't comply with Google's demands. They're uncertain of whether developers and users will support them if they break compatibility with the browser currently holding the highest market share.

If that's the case (as it seems to be), then the most effective means we have at our disposal to produce a better outcome is letting would-be competitors know that there's an opportunity to claim some market share by remedying our dissatisfaction with the way Chrome is headed. This form of protest here is the only real option we have available, and it aims to unravel all of these issues addressing the "elephant in the room" which brings us all here today (the third point in the numbered list above).

Whichever major browser vendor takes a bold move by breaking ranks with Google's direction has a great shot of reaping the massive rewards for doing so. Perhaps resisting the MV3 transition is the inflection point Mozilla needs in order to save Firefox from dying. In doing so, it might be able to become the dominant browser on desktop once more (rather than being in its current position of living on life-support solely through the revenue from a single Google advertising deal). When people use desktop computers over their phones/tablets, it's generally in order to be more productive, after all. Features are therefore paramount; Very few people using a desktop computer in 2022 want a web browser that's so crippled that you can hardly do anything with it.

So my "constructive criticism" is this:

Two can play the "stubborn hardline stance" game, and therefore I strongly suggest that a company outside of Google has the courage to stand up for users' needs by taking the inverse hardline stance. Be bold, rather than timid. Don't let the situation degrade merely for the sake of avoiding conflict. Build a system which helps people accomplish things!

At this point, I don't even care whether browsers are compatible with one another anymore. It would have been nice to deploy a product to multiple browsers at the same time from the same codebase, but if this MV3 standard becomes widespread, there's a serious risks of not having a product to deploy in the first place!

If perhaps Safari breaks ranks and ends up becoming the only browser with the features that my users are demanding, then I will develop for Safari-only, and I will tell my family, coworkers, customers, etc., to buy only Macs just so that they can use only Safari from that point forward. I will update my Upwork profile to say "Safari Extension Specialist" (rather than the "Chrome Extension Specialist" headline I've been using). If that's what I need to do in order to satisfy my extensions' users and the people who ask me to make them, I'll do it. I'm growing tired of telling prospective clients: "I could have created that extension for you last year, but Google is crippling Chrome, and so now it's simply impossible to create what you're thinking of".

To implementors: Please don't take the bait and fall for Google's revival of Microsoft's former "Embrace, Extend, Extinguish" strategy. Becoming more interoperable with Chrome's peculiarities is more likely to end with you bleeding users rather than gaining more. If you become interchangeable with Chrome during a period when most people are already comfortable using Chrome, why would anyone even bother switching to your browser? Extensions are not the web; There's no inherent need to comply with a harmful standard simply for the sake of compatibility.

We extension developers are the main (and perhaps, sole) reason Chrome rose to prominence. We can switch teams at any time if given an effective platform and a good reason. If this community group is going to succeed, it needs to start genuinely respecting the views of individual extension developers, rather than being dominated by browser implementors (particularly Google). It's very disrespectful for those with the highest power to improve things to maintain the facade of open discussion if they won't take others' perspectives seriously.

I'd like to encourage constructive critcisim over outright rants.

I don't understand why you interpreted my previous comment as a rant. I pointed to an actual way out to this conundrum we are all immersed in.
I've been reading the Chromium Extensions forum since the big MV3 announcement of January 2019, and I've seen many good proposals and ideas of how to solve the limitations imposed by MV3. There's been no lack of feedback from the community.
But at the same time I've also seen that Google has shown no interest whatsoever in deviating from their original plans. So, it's quite clear what's happening here. MV3 is a business decision, not an engineering decision.

As developers, we can contribute with practical solutions that actually work. But Google has shown no interest in what works. They have other priorities.

So, as an engineer that cares about courses of action that actually work, I can see that a competitor to Google's dominant position is something that can actually have an impact on the current situation.
Proposing solutions has shown to be futile. It seems like the developers community has been talking to a wall for the past 3 years.

An easy workaround of this restriction for chrome-extension:// URLs is shown in https://crbug.com/1239976 and as long as it isn't physically disabled, there'll be always a possibility for an extension to evade the review process in the web store, which means that malicious actors will inevitably abuse it for they aren't concerned with reputation of their accounts, which they can register in abundance anew.

It means that the only victims here are the good extensions and the users. The majority of users will believe ManifestV3 propaganda that it's safe, and hence will be less wary to install new extensions suggested by a malicious web site or in a viral meme video.

Although this workaround won't help with registering a remotely-supplied content script, the malicious extensions will simply run such code in the main world of the page after stripping its CSP header so only the sites with a <meta> HTML tag for CSP will be able to thwart it, but then an extension can add a chrome-extension:// iframe and run arbitrary code there using the easy mode workaround above. Some other tricks: reusing the site's nonce from any of its script elements or redirecting some of its script URLs to a data: string with the new code.

Tampermonkey now has registeredContentScript, which may help part of their problem with making a userscripting extension, but they still seems to be struggling with existential questions around how they can continue to function without dynamic code execution. Tampermonkey/tampermonkey#644

If that's the case (as it seems to be), then the most effective means we have at our disposal to produce a better outcome is letting would-be competitors know that there's an opportunity to claim some market share by remedying our dissatisfaction with the way Chrome is headed. This form of protest here is the only real option we have available, and it aims to unravel all of these issues addressing the "elephant in the room" which brings us all here today (the third point in the numbered list above).

I agree fully with you @cuylerstuwe the MV3 "constructive" discussion has gone on for years, can anyone realistically say that from the introduction of MV3 that Chrome listened and adjusted in a substantial way?

The discussion needs to move to the browser that will take over market share.

Cutting dynamic code kills my MV2 extension (an ultra micro insignificant nothing extension, code came in from a native client) I spent hours writing it, was proud of my work (i'm a beginner) and the people that used it loved it. I have communicated to people, Jan 23 it dies, no updates.

I know, as technology evolves there are updates but MV3 is so sad and unexplainable it leaves me with a bad taste in my mouth.

I agree, this is incredibly disappointing. My personal extension, which I use to customize the web to my liking, is now far less effective and empowering. This is a really bad change.