Content blockers and Chrome's Manifest V3

By Jake Edge
December 21, 2021

A clarion call from the Electronic Frontier Foundation (EFF) warning about upcoming changes to the Chrome browser's extension API was not the first such—from the EFF or from others. The time of the switch to Manifest V3, as the new API is known, is growing closer; privacy advocates are concerned that it will preclude a number of techniques that browser extensions use for features like ad and tracker blocking. Part of the concern stems from the fact that Google is both the developer of a popular web browser and the operator of an enormous advertising network so its incentives seem, at least, plausibly misaligned.

Manifest V3 was first proposed in late 2018 as an eventual replacement for Manifest V2, which is the current extension API that is supported by both Chrome and Firefox. These APIs provide the tools that extensions use to manipulate the browser state to customize the web-browsing experience in some fashion. Extensions can change the user interface in various ways, observe and modify the browser behavior for things like bookmarks and tabs, manipulate the requests (and their content) that the browser makes, and more.

There are two main changes that Manifest V3 makes which are problematic for various types of content blockers. The first is the removal of the ability for extensions to block requests that the browser makes using the webRequest API. Instead, extension developers would need to use the much more restrictive declarativeNetRequest API, which has limits on the number of rules that can be used for blocking sites. The EFF described the impact of that change in a mid-2019 post highlighting problems with Manifest V3:

Currently, an extension with the right permissions can review each request before it goes out, examine and modify the request however it wants, and then decide to complete the request or block it altogether. This enables a whole range of creative, innovative, and highly customizable extensions that give users nearly complete control over the requests that their browser makes.
Manifest V3 replaces these capabilities with a narrowly-defined API (declarativeNetRequest) that will limit developers to a preset number of ways of modifying web requests. Extensions won't be able to modify most headers or make decisions about whether to block or redirect based on contextual data. This new API appears to be based on a simplified version of Adblock Plus. If your extension doesn't work just like Adblock Plus, you will find yourself trying to fit a square peg into a round hole.
[...] For developers of ad- and tracker-blocking extensions, flexible APIs aren't just nice to have, they are a requirement. When particular privacy protections gain popularity, ads and trackers evolve to evade them. As a result, the blocking extensions need to evolve too, or risk becoming irrelevant.

The second change is a switch away from background pages, which are currently used by extensions to perform tasks behind the scenes, to service workers, which are meant for a different use case than extensions. Content blockers currently use background pages to continue to monitor requests being made from pages for as long as the user still has the page open in a tab. In that way, ads and other undesirable content that gets requested well after the main page gets loaded can be handled based on the extension's requirements. But service workers are shut down after five minutes, which means that any initialization done for the extension is lost; meanwhile, any background processing stops too. The shutdown is meant to reclaim the memory being occupied by those worker processes, but extension developers sometimes need to keep it around. The EFF described some of the problems with all of that in a November blog post:

In short, Service Workers were meant for a sleep/wake cycle of web asset-to-user delivery—for example, caching consistent images and information so the user won't need to use a lot of resources when reconnecting to that website again with a limited connection. Web extensions need persistent communication between the extension and the browser, often based on user interaction, like being able to detect and block ad trackers as they load onto the web page in real time. This has resulted in a significant list of issues that will have to be addressed to cover many valid use cases.

The timeline for Manifest V2 support in Chrome, which was published in September, shows a limited runway for extension authors before they need to "upgrade". In January 2022, the Chrome Web Store will stop accepting new Manifest V2 extensions, except for those marked "private", which means they are only available to users in a specific organization. In June 2022, new private V2 extensions will be banned. Any existing V2 extensions can be updated until January 2023, but after that, Chrome is effectively V3-only.

Some of the changes in Manifest V3 seem unambiguously positive, however, including the removal of remotely hosted code for extensions. It is, of course, impossible to ensure that an extension does what it is supposed to, and does not, for example, send tracking information off to some dodgy site, if the code can be changed from afar.

The reasons behind Manifest V3 seem reasonable as well. In the announcement of its availability in Chrome beta versions, almost exactly a year ago, those reasons come down to security, performance, and privacy, though much of that is overblown or inaccurate according to the EFF. There seems to be a clear disconnect between how existing content-blocker extensions work—how their users want them to work—and how Google views the privacy threats inherent in the existing extension API:

For extensions that currently require passive access to web activity, we're introducing and continuing to iterate on new functionality that allows developers to deliver these use cases while preserving user privacy. For example, our new declarativeNetRequest API is designed to be a privacy-preserving method for extensions to block network requests without needing access to sensitive data.
The declarativeNetRequest API is an example of how Chrome is working to enable extensions, including ad blockers, to continue delivering their core functionality without requiring the extension to have access to potentially sensitive user data. This will allow many of the powerful extensions in our ecosystem to continue to provide a seamless user experience while still respecting user privacy.

Of course, content blockers are perfectly positioned to have a lot of detailed information about what their users are doing on the web. That is, obviously, exactly the point. As long as those extensions only use that information locally, and for the benefit of their users—not the developers or corporate owners—all should be well. That's not to say we have not seen malware in web extensions, including ad blockers, but those are the kinds of problems best addressed through extension vetting, both by browser-extension stores and the user community. Restricting content blockers to the actions Google (or anyone) thinks they should be able to do might seem safer, perhaps it even is, but it seems to mean that the kinds of content blocking available to users is being drastically curtailed in Manifest V3.

The EFF had some suggestions for better ways to address the problems in its November post. Not requiring a switch to declarativeNetRequest was first on the list. Extensions that only need the functionality provided in that API could make the switch, while: "Extensions that use the blocking webRequest API, with its added power can be given extra scrutiny upon submission review."

For its part, Mozilla has decided to take something of a middle course. It wants to support cross-browser extension development, so it will implement Manifest V3, but will not force the use of declarativeNetRequest (which Mozilla abbreviates as "DNR"), at least for now:

After discussing this with several content blocking extension developers, we have decided to implement DNR and continue maintaining support for blocking webRequest. Our initial goal for implementing DNR is to provide compatibility with Chrome so developers do not have to support multiple code bases if they do not want to. With both APIs supported in Firefox, developers can choose the approach that works best for them and their users.
We will support blocking webRequest until there's a better solution which covers all use cases we consider important, since DNR as currently implemented by Chrome does not yet meet the needs of extension developers.

That Mozilla blog post is from May, but it is in keeping with Mozilla's position as described in its Manifest V3 FAQ from 2019. While the company wants to be as compatible with Chrome as it can be, Mozilla says that it will not blindly follow Google's lead if those changes negatively impact its users and developers. The question of background pages versus service workers is less clear, however, though Mozilla was still working on the feature as of May. It is being tracked in a Bugzilla bug, which mentions several use cases where service workers will not provide an adequate replacement.

In general, this seems like a fairly heavy-handed approach from Google. It has a dominant position in the browser market and plausible reasons to want to restrict ad blocking, so the claims that Chrome is simply making ad blockers safer is not completely believable, at least for some. In addition, extension authors have said that it will be difficult or impossible to accomplish their tasks using Manifest V3. For example, the EFF's Privacy Badger extension for blocking invisible trackers will be hampered:

It appears that Privacy Badger will no longer be able to dynamically learn to block trackers, report what it blocked on a page, block cookies from being set or sent, strip referrer headers, nor properly support EFF's Do Not Track policy.
If you remove what makes Privacy Badger unique, replacing it with basic list-based blocking, what are you left with?

Similarly, the uBlock Origin ad-blocking extension will be unable to continue doing its job, as described in a GitHub issue. UBlock Origin developer Raymond Hill ("gorhill") has commented multiple times in the bug about problems stemming from the switch to Manifest V3. Most recently, he said:

Given how the deprecation of a blocking webRequest API put a lid on innovations (and regressions in capabilities in the case of uBO [uBlock Origin]) regarding content blocking, it does seem the move could be the "Not-Owned-But-Operated" strategy applied to content blocking -- the declarativeNetRequest API means the capabilities of (not-owned) content blockers are ultimately operated by Google through the limitations of the API the content blockers must use.

In a lengthy Reddit thread about the EFF's most recent Manifest V3 post (naturally there is another on Hacker News), "Brawl345" wrote that Manifest V3 made a lot of things easier for them, but did recognize that there are a number of shortcomings, including the ability to do dynamic filtering.

In general, Manifest v3 is a good idea but executed in the wrong way. I'm actually one of the few people in this thread (I bet) that actually ported some of my extensions to Manifest v3 and there are many good parts and some bad that make the whole experience kinda bad.

What seems clear, though, is that Chrome users will have less-capable content-blocking extensions available starting next year. That will, perhaps, decrease the capabilities of malicious extensions, thus increase the security of Chrome users from those kinds of threats. But privacy-conscious users, who seemingly only make up a tiny fraction of browser users anyway, will want to make a switch to Firefox—if they haven't already.

Hopefully, by 2023 (or sooner), Google will relent on the most onerous restrictions, but that hope may well be forlorn. On the other hand, there is good reason to believe that Mozilla will keep providing features that are useful for content blocking even if it means extension developers have to maintain two versions. And in the meantime, maybe "everyone" can come up with a standard for browser extensions that serves the needs of all web users, regardless of their interest in being the product. Hope springs eternal.

Index entries for this article
Security	Content blocking
Security	Web browsers

to post comments

Content blockers and Chrome's Manifest V3

Posted Dec 21, 2021 1:34 UTC (Tue) by tux3 (subscriber, #101245) [Link] (2 responses)

Mozilla not following suit really throws a wrench in my cynicism.

Chrome imposes web infrastructure, standard bodies write those down, and Mozilla follows. Isn't that how this works? :')

I'm probably sticking with Firefox until the bitter end, but it'd be nice for the health of the web if they managed to stabilize their decade old marketshare hemorrhage. It doesn't do much good when the standards are set by a non-neutral for-profit party whose goals don't necessarily suffuse altruism for end-users

Content blockers and Chrome's Manifest V3

Posted Dec 21, 2021 2:40 UTC (Tue) by tau (subscriber, #79651) [Link]

"We only need to be lucky once, you need to be lucky every time".

Google exerts considerable financial leverage over the Mozilla organization. That $X million dollar per year salary for their CEO doesn't come from nowhere.

Content blockers and Chrome's Manifest V3

Posted Dec 21, 2021 7:25 UTC (Tue) by roc (subscriber, #30627) [Link]

I don't think standards bodies govern extensions at all.

Content blockers and Chrome's Manifest V3

Posted Dec 21, 2021 9:10 UTC (Tue) by eru (subscriber, #2753) [Link] (3 responses)

Wonder what the now Chromium-based Microsoft Edge will do? Or Chromium itself?

Content blockers and Chrome's Manifest V3

Posted Dec 21, 2021 9:34 UTC (Tue) by ibukanov (subscriber, #3942) [Link]

Chrome is Chromium with few Google-specific extra components. Extension API changes happens in Chromium code.

In principle any product based on Chromium can continue to support Manifest v2 by keeping the code that Google will remove from Chromium in one year. But such patch will quickly became very expensive to maintain as Google refactors the code.

Content blockers and Chrome's Manifest V3

Posted Dec 21, 2021 9:40 UTC (Tue) by soal (guest, #110838) [Link] (1 responses)

Edge follows Chromium.

Content blockers and Chrome's Manifest V3

Posted Dec 22, 2021 20:20 UTC (Wed) by JanC_ (guest, #34940) [Link]

Microsoft has its own spyware & ads divisions, so they benefit from it too…

Content blockers and Chrome's Manifest V3

Posted Dec 21, 2021 9:52 UTC (Tue) by eliezert (subscriber, #35757) [Link] (8 responses)

The community needs to go for the nuclear option:
A plugin that clicks on _all_ the google adds and opens them in hidden windows.

Content blockers and Chrome's Manifest V3

Posted Dec 21, 2021 10:16 UTC (Tue) by sadoon (subscriber, #155365) [Link] (4 responses)

That's actually awesome.
Would ruin Google completely if all the clicks started becoming fake.

Content blockers and Chrome's Manifest V3

Posted Dec 21, 2021 10:47 UTC (Tue) by GhePeU (subscriber, #56133) [Link] (2 responses)

And then Google will just declare that it's a harmful and abusive extension and ban all its users from its services: say goodbye to your Gmail accounts and to all the emails they contain, to all your files saved on Google Drive, to your pictures on Google Photo, to every Android app you ever bought, to all your documents on Google Docs, Sheets and Slides, to all the websites you use Google to login to, and so on.

Google was allowed to gain too much power and now it's too late for individuals, or even communities, to do anything about it.

Content blockers and Chrome's Manifest V3

Posted Dec 21, 2021 13:55 UTC (Tue) by niner (guest, #26151) [Link] (1 responses)

I just realized: none of these things would affect me. Must be doing something right...

Content blockers and Chrome's Manifest V3

Posted Dec 21, 2021 14:14 UTC (Tue) by zdzichu (subscriber, #17118) [Link]

Yes, you are not thinking generally enough. GMail has 1.5 billion of users on this planet. People in civilised countries without gmail account – like you – are outliers. Not relevant to mass-ad-clicking plan.

Content blockers and Chrome's Manifest V3

Posted Dec 22, 2021 13:56 UTC (Wed) by awww (guest, #122021) [Link]

I think most clicks on ads probably are fake just nobody is willing to admit it. I can't remember a time I deliberately clicked an advert. All the ads I've clicked lately have been accidental clicks caused by reflows and the anti pattern of moving interactive elements around after enabling interactions. That stems from the insane amount of JavaScript that some sites use these days meaning the layout is still changing long after it ought to have completed, caused by yep, the whole ecosystems. Anecdotally I'm far from the only one in this position. Throw in the shadier end of the market (disguised adverts, ads in kids apps etc.) and you don't even need fraud to see a very large percentage of total "clicks" not representing real "engagement" in any meaningful sense.

Content blockers and Chrome's Manifest V3

Posted Dec 21, 2021 11:47 UTC (Tue) by DeletedUser105633 ((unknown), #105633) [Link] (2 responses)

>A plugin that clicks on _all_ the google adds and opens them in hidden windows.

This addon already exists. It was created in 2014, then banned from chrome in 2017.
It is called AdNauseam.
https://github.com/dhowe/AdNauseam

It is a fork of uBlock Origin where in additional to ads being hidden, they are sent false clicks.
Though as these sites are sent reply connections, it carries a different privacy model than outright blocking them.

Do note that being based on uBlock Origin means it will be just as crippled by Manifest V3.

Content blockers and Chrome's Manifest V3

Posted Dec 31, 2021 1:41 UTC (Fri) by flussence (guest, #85566) [Link] (1 responses)

There once was another extension that replaced utm_* tracking in URLs with garbage, having a similar outcome without the added junk traffic, which sadly seems to have vanished from the internet.

Content blockers and Chrome's Manifest V3

Posted Jan 19, 2022 17:25 UTC (Wed) by locrelite (guest, #156332) [Link]

The extension vanished from Chrome store, but the bookmarklet lives on: https://github.com/huntwelch/UTM-Mangler

Content blockers and Chrome's Manifest V3

Posted Dec 21, 2021 10:43 UTC (Tue) by ras (subscriber, #33059) [Link] (2 responses)

> What seems clear, though, is that Chrome users will have less-capable content-blocking extensions available starting next year.

On Android it's not a case of Chrome having "less-capable content-blocking extensions". That's impossible - it doesn't support them, at all. That's a pretty good measure of how cognisant 90% of the people are of this issue.

Some claim the ordinary person doesn't care about privacy - but I suspect if they understood the speed and privacy implications a great deal of them would care. "Not cognisant" seems a better explanation to me. But them not being cognisant is no accident. There is absolutely no doubt in my mind Google has cleverly, and unobtrusively engineered the computing fabric of the planet so all of our data ends up on their servers.

From this perspective, the free OS Android is really a trojan horse acting as a conduit for a browser that not only does not do content blocking, it lacks any of it's desktop cousins ability to block data feeding into those pipes. And it's not really free. Admittedly the cost is almost nothing - merely creating an identity on Google. And once you do that they helpfully provide calendaring, mail that will create calendar entries for plane trips and restaurant bookings that end up in your Inbox, a contact list so they can establish the links between all your family, friends, associates and work colleges, video calling, authentication to other platforms, mapping that helpfully takes you to home and work if you tell them where that it is (and free tracking of your daily movements), a camera and free storage for the photos, even a search facility for those photos can find all your family and associates by name using via face recognition (implying they've tagged every person in every photo beforehand). Hell, if you establish multiple identities in some pathetic attempt to preserve privacy, it learns them all, and offers to link them all together so you can regain control of one from another. It's all so undeniably helpful, all so reasonable, done so smoothly you hardly know you are being wrapped in a web CC’ing all your information to Google.

I guess I should not be surprised. A ceiling fan died in my house recently. It's just a ceiling fan right - what possible hook could the death of a ceiling fan provide to Google? With one eye on a fan that is never turned off (or even down) and another on the power bill (did you know a 71W motor consumes 1.7kWh per day - or AUD$150/yr) I wanted to replace it with ceiling fan with an efficient motor, which nowadays boils down to a brushless DC motor (which typically use 1/2 the power of the old induction motors). A brushless motor is really an AC motor, but the frequency of the AC is varied to match the fan speed. To do that they have to rectify the 240V AC to DC, then "invert" the DC back to AC at the desired frequency, which needs so much silicon you may as well add computer because a dual ARM M0 (perhaps in the form is an ESP822) is all of $1 or so, and if you have a computer then why not have 6 speeds controlled digitally rather than some analogue control, but you don't send such signals over a 240V wire and you sure as hell aren't going to ask the customer to run a new network cable for this fan - so they use wireless. But no one has standardised the wireless protocol so if the controller dies, dropped or is grand-kidded you've lost the fan. Such is progress.

Fortunately Google (and Amazon/Alexa) has come to the rescue, and producing a standardised protocol that works with everything(!) Not only does it work with everything - but it means you can get rid of that finicky proprietary wireless controller and for the measly price of dotting your house with spy^H^H^Google home devices (that will remind you to wake up when that plane flight gmail helpfully added to your calendar comes up), you can just speak to the thing. In fact, even the fan running all night can no longer be a concern - because for the tiny price of you telling Google your daily movements it will be turned off when not needed. And that Google clock you talk to and wakes you up for every important event can and does watch body movements as you sleep, helpfully making health suggestions by tracking sleep patterns.

Who here has read George Orwell's 1984? To be fair it was 1984, not 40 years later. But even so, he got it so, so wrong. Here he was thinking they would be hiding microphones behind wall paintings. Hiding - really? I bet he even thought the spies would be paying for microphones. We pay Google $1,000 to buy a device that knows so much about what we do, I use it to track my incidental exercise to ensure I get my 150 heart points. (I know I do because my phone congratulates me every time I do it.) The transparency of the Orwellian government's motivations seems so quaint, compared to a company that spent a decade building what is arguably the most powerful and secure OS on the planet, and then giving it away for free - all so they could mine the data it collected. In a tilt to Orwell, should the government want to know any of this, they just subpoena the spider at the centre of the web - Google.

Sorry, where were we? Oh yes - Mozilla doesn't really agree with the way Google is improving the flow of data into its web, and I'm guessing a lot of people here sympathise. I get that. But for all 99% of the planet knows we may as well be discussing the meaning of the wave function collapse, and frankly the physicists have somehow made discussing the philosophical meaning of a quantum observation a far sexier topic than Google knowing more about their daily habits than their imitate partner.

It is a truly awe inspiring achievement. And methinks the horse had bolted long before the manifest V3 proposal.

Content blockers and Chrome's Manifest V3

Posted Dec 30, 2021 9:02 UTC (Thu) by k8to (guest, #15413) [Link]

For my part, I wasn't aware of this situation because I never use Chrome even on Android. I was pretty shocked to figure this out a few months ago.

For this reason I'm starting with Firefox on Android for as long as they're supporting privacy enabling extensions.

Of course, most people won't bother.

Content blockers and Chrome's Manifest V3

Posted Jan 9, 2022 11:27 UTC (Sun) by oldtomas (guest, #72579) [Link]

It's not 1984. It's Brave New World, as this [1] wise person says in her podcast (alas, in German).

Orgy Porgy!

[1] https://blogs.taz.de/dissenspodcast/katika/

Using blocking VPN or network-lever filters instead of extensions?

Posted Dec 21, 2021 16:28 UTC (Tue) by kronat (subscriber, #117266) [Link] (6 responses)

I wonder if Manifest v3 will be the ultimate reason to install and use network-level filter programs, such as Blockada for android or pi-hole for Linux.

Using blocking VPN or network-lever filters instead of extensions?

Posted Dec 21, 2021 17:17 UTC (Tue) by NightMonkey (subscriber, #23051) [Link]

I have pfBlockerNG set to block ads on my home wifi network (with a DNS-based blocklist), and have created several WiFi nets + VLANs alignments to segment traffic. In addition, I set up one WiFi network +VLAN combo as an endpoint for a VPN provider's client, so connecting to that network means you have left the country. :D I think that this is the only reliable way to block ads and to offer greater digital privacy within a home.

And, no, it's not easy for someone who doesn't know the technology to set this up. And that's a shame.

Using blocking VPN or network-lever filters instead of extensions?

Posted Dec 22, 2021 4:24 UTC (Wed) by edgewood (subscriber, #1123) [Link] (2 responses)

<conspiracy mode="on">
That, of course, is why they are promoting DNS over https, to close that escape route.
</conspiracy>

Using blocking VPN or network-lever filters instead of extensions?

Posted Dec 23, 2021 5:44 UTC (Thu) by dw (subscriber, #12017) [Link] (1 responses)

One need only firewall DoH to trigger downgrade, but it's unclear how long that will last.

Using blocking VPN or network-lever filters instead of extensions?

Posted Dec 23, 2021 18:46 UTC (Thu) by kpfleming (subscriber, #23250) [Link]

It's not practically possible to firewall DoH, because it's just HTTPS, and the connection could be made to any random site.

Sure you can block port 443 to the major public resolvers, and even your ISP's resolvers, but the end game is that some site which really wants to avoid your blocks will just run a resolver on its own obscure URL that you'll never see (or as additional traffic on the main URL).

Using blocking VPN or network-lever filters instead of extensions?

Posted Dec 22, 2021 20:20 UTC (Wed) by MatejLach (guest, #84942) [Link]

The problem is that DNS level blocking is static i.e. it can't block YouTube ads dynamically like uBlock Origin can.

Using blocking VPN or network-lever filters instead of extensions?

Posted Jan 20, 2022 10:13 UTC (Thu) by Klavs (guest, #10563) [Link]

I think proxy applications like privoxy is the only thing that works.. and HOPEFULLY browser adheres to proxy settings and routes ALL requests through it. It works 'fairly well' for me atleast :)

Content blockers and Chrome's Manifest V3

Posted Dec 24, 2021 4:45 UTC (Fri) by calumapplepie (guest, #143655) [Link]

I want to say something about the security benefit of this change.

It is certainly nonzero: one of the 'common posts' in the Great Suspender issue report was that Manifest V3 would prevent the attack from occurring again. There are two major ways it does so. First, it is because the extension had the WebRequest permission that it was able to provoke such fear. That permission allows a huge variety of operations on every single interaction your browser has with the outside world. An extension with that permission is able to read, for instance, the exact details of your bank account login (compromising your password), or the auth token included with your request to Gmail for your email (which would allow it to bypass 2FA in most (all?) cases), and send it to a server, for arbitrary fun. In terms of actual damage on a typical user, I'd argue this capability is even better than a root shell: with a root shell, you might be able to harvest everything on the user's computer, but this ability allows you to get everything they have on the cloud.

The article goes into great depth about why that immense power is also very useful to have available. There are lots of extensions that leverage it for good; PrivacyBadger would be non-functional without that visibility into what a site is doing with its requests, uBlock Origin is dependent on having both that power and the ability to make web requests, and LocalCDN needs to be able to manipulate the redirected request for a CDN resource to remove all possible tracking cookies (to name a few off the top of my head). However, it is also an access that it isn't clear you are giving to an extension. Variations of the "Read and manipulate your data on all the sites you visit" message are shown for most extensions, causing users not to consider what exactly they are signing away to an anonymous maintainer.

However, that's a completely moot point if you consider the 2nd relevant change. By blocking the loading of remote code (as Firefox has done for ages), it becomes impossible to execute the Great Suspender attack (or at least to execute it without being blatantly obvious). The problem with the attack was that it was loading and executing Javascript loaded from a remote server. There is no way to verify that remote code is behaving in a certain way: the attacker can change it at any time, or even make it selectively return the malicious code. We never actually determined what the attacker did to The Great Suspender users: perhaps we should've been better at getting actually security people to look at the problem.

------------------------

The point I'm trying to make, in a painfully roundabout way, is that while the NetRequest API is powerful and an attackers wet dream, it is also important. It's not inherently much more risky than, say, content script injection (which is what allows extensions to actually modify the site you see, in ways more fine-grained than simply yeeting[1] away entire blocks of Javascript). Blocking this ability without addressing the underlying problems of the extension ecosystem is pointless. It isn't like those are hard to do: simply blocking remote code, and doing a non-zero amount of review is enough. Mozilla manages it just fine: why can't Chrome do the same?

[1] yeet (v.): to fling an object, without care for where it goes or what happens to it when it lands.

TLDR: Manual review solve security of web extensions better than Manifest V3, and no break useful extensions.