What an unmitigated disaster. Anyone who has been following the MV3 transition saw this coming from a mile away. When I wrote the MV3 chapter for "Building Browser Extensions", it was nearly impossible to commit to any content because there was so little clarity or direction.
I suppose Google gets a tiny bit of credit for not jamming MV3 through and leaving developers with the bill, but given the state of things, who has any confidence in what the future of browser extensions holds?
Note that Google's collection doesn't seem to include all of their extensions. For example, they are missing Google Voice, Google Dictionary, Send from Gmail, Page Analytics, Google Tone, Chrome Web Store Launcher, RSS Subscription Extension, Google Scholar Button, IBA Opt-out, Google Mail Checker, Google Similar Pages, Endpoint Verification, Chrome Remote Desktop, Chromebook Recovery Utility, Certificate Enrollment for Chrome OS, Screen Reader, Print, Google Docs Offline, and I'm sure there are plenty of other Google extensions that I missed in my search. Some of them have been abandoned for a number of years.
Also, this site [1] has been tracking Manifest V3 migration, but I think they might be incorrectly including Apps and Themes in their counts (I believe the 180K figure represents all of the items on the store [2]) which might be throwing off the numbers a bit.
Im afraid this statistic wont tell you the whole picture because there are things strictly prohibited/not supported by v3. 100% v3 will simply mean all the extensions using those APIs simply got deleted and no longer exist.
Firefox and Safari are continuing to support HTML pages to run the background code in rather than forcing developers to use service workers with no DOM access.
I don't think the best practices are necessarily the requirements for the featured badge. Manifest V3 is not yet a requirement for being featured, for example look at the listing for uBlock Origin, which still uses Manifest V2.
Eh, before the post in OP, I believe the timeline was June 2023 MV2 extensions go unlisted and January 2024 they get deleted. People do procrastinate but we're still far from 2/3 being "broken".
It was inevitable to delay the rollout, the adoption of Manifest V3 is way too low among the most popular extensions. Take a look at the various featured categories on the Chrome Web Store, only a small fraction of featured extensions have migrated to Manifest V3. In 3 weeks all of them would have had to be removed from those promotion pages and the Chrome Web Store would have been in ruins.
The deprecation timeline is too aggressive considering that Manifest V3 is still missing important features, so many developers have decided to brace for impact, even if it meant losing the Featured badge for their extensions in January 2023.
I’ve seen Google deprecate a dozen products I’ve used. They all follow the same pattern:
1) Deprecation announced with shut down date
2) 1-2 months before the day, they’ll send an email saying the shut down is delayed by 3-12 months
3) Repeat steps 1-2 until enough people have migrated away
The same thing will happen with Google Analytics, scheduled to be disabled July 2023. There’s no way Google will turn off millions of Analytics (GA3) accounts in 6 months when their replacement product (GA4) is so inferior.
I was a really big stadia fan. Controller and dozens of games. Hundreds of hours in game. Everyone said it was going to shit down and I did believe them but said no way they would leave us hanging. Got every penny back from them. So at least with stadia the few that believed in them made out with free gaming over the last years (and a free useless controller)
I wont mention what company, but where I work we've spent about 6 months now with an entire dev team hammering their heads against a wall trying to port our extension to MV3, because the alternative was to lose it entirely at the deadline.
Hacks, workarounds, bad docs, and lately, Google pops up to tell us OSD is kinda sorta a thing you can use, but clearly it's at a basically alpha level of maturity. This latest announcement might seem like a reprieve, but it's even worse than before for us, because now it's clear that OSD is a temporary measure, and now we have promises to fix the actual issues in the future.
As a manager I have no idea how to proceed. Do we solider ahead with OSD like we planned? Wait for them to fix the core issues? We have so little trust in Google fixing things, and a great deal of confidence in them making things worse at this point. If we commit to OSD we might be looking at doing the same level of work again, when they fix the core issues and deprecate it. If we wait for core fixes, we might not get the work done before a nebulous future deadline that could drop on us at any moment.
Google has caused us to burn an absolutely incredible amount of time and money with this. Believe me, we're are footing the bill, and have been for some time now.
Doesn’t matter. The only people who take Google seriously now are the people who took IBM seriously yesterday.
Google isn’t the CIA or NSA. They don’t have that kind of staying power because they don’t have any guiding principle beyond profit (for better or for worse).
Google dominates search, browsers, and mobile operating systems. CIA and NSA inly wished they had this (well, thanks to CLOUD Act they do, through Google and others).
People not taking Google seriously is precisely why all this shit like Manifest V3 is happening.
Chrome without ad blocking will quickly drop from the top spot.
As for search: Google has been watering down search for years trying to make it "understand" human speech. This has been a failure and not ChatGPT exists that can actually (apparently) understand english and replies in English too. It's an excellent first pass to get me the information I'm after. The responses from ChatGPT leapfrog me over the first 4-5 rounds of Google searches and right to the point where simple 1-2 word searches on google/bing can get me across the finish line.
I think that the viewpoint is that no dominator lasts forever. Not so weird then.
I think that we had two or three browsers be the dominator already and then going away.
> I felt MV3 is really about limiting what the extensions can do.
You felt that way because that's exactly what it's about. It's about doing everything possible to increase ad revenue in the name of "increased security".
I developed an extension[1] after the Chrome Store stopped accepting MV2, but before Firefox support for MV3 in stable. I had to write some custom build scripts to build the extension with MV2 for Firefox and MV3 for Chrome. Pretty annoying.
Yeah the state of Chrome's extension API documentation is awful. It needs to be totally reorganized and partially rewritten. I'm hopeful that MDN will become a better resource as Firefox becomes more compatible with the APIs. It's already more helpful in some places.
I spent a few days on a pet project using the Google Sheets API and the official docs use a mix of 3 different versions of libraries, none of which are really up to date, and you have to guess which is the right one.
It's more than just good stuff rotting. It's a fundamental lack of care, or maybe inability to ship anything that represents a big iteration. On the Google Analytics side, they are preparing to turn off data collection from the existing version of Analytics in 6 months and have been telling everyone to migrate to the new version for months now - but their "migration guides" are missing crucial technical detail, fall out of sync with the state of the new product a mere month or so after publishing, or contradict each other. It's like the whole effort of documentation has just been outsourced to the world of blogspam. Meanwhile, they started aggressively pushing for users to migrate their data collection when the new product itself didn't support some of the most basic use cases that needed to be migrated. Something is just off with Google's ability to ship these days.
Funny, I've been using the MDN docs and took a look at the Chrome docs today. Some of the conceptual info was easier to track on the Chrome docs where the Mozilla side seemed to jump too low level too quickly.
Ideally, those docs should just be in one place so writing Chrome/Safari/Firefox extensions should just work.
> the Mozilla side seemed to jump too low level too quickly
This is literally my only complaint about MDN, and it’s only a complaint when I’m in a hurry. The sprawling body of standards MDN documents are almost all fairly low level and intended as such, and MDN mostly does a good job of balancing the low level details with good boilerplate examples. I can’t say how this is for extensions on any version, but if the MDN docs continue apace I’d be surprised if they don’t at least adequately answer this “should” as shortly behind a stable spec as anyone could wish for.
I wish XML-related tech was such a hot documentation commodity… guess I better contribute as I go :)
I maintain the Enketo[1] projects for ODK[2]. The latter is a little more flexible and stable on the XML front, but the former is currently in the position of using a lot of nonstandard XML tooling despite being well positioned to use existing browser tech, and at the same time may be better off migrating to many of the same abstractions ODK already uses.
MV3 has some changes that are genuinely good, even if those may feel inconvenient to develop for, mixed in with the genuinely bad. For FF you can get the best of both worlds though since their MV3 implementation isn’t removing the controversial deprecations/plans.
I'm in a similar boat, wrote a MV2 plugin for firefox, started looking at MV3 got confused about which bits are going to be usable and which are not and when. Ends up being too difficult.
From a extension creator perspective, it might be better to just pull all mention of MV3 on the MV2 pages until it's properly baked.
> MV2 will continue to work. We have not made decisions about MV2 deprecation yet. We want to see what the response and adoption of MV3 is from the community next year and will then make decisions about the future based on that.
But really, the prospect of breaking support for the innumerable applications that use V2 and will never be updated seems to be the worst idea Ive seen in decades.
I still struggle to believe it, but everytime I read something on this "V3 migration" that sounds like exactly what they plan..
This isnt like IE6 either, where every user was desperate for the apps they were forced to use to die, it seems the only people that really want this change is google.
Apologies in advance if Im wrong, the only reason I care is I keep hearing "google plans to break lots of stuff with no clear need to do so."
They're the only ones who want this change because they're the billion dollar advertising corporation and they want to kill ad blockers on Chrome. The more painful and costly it is for them, the better. Hopefully it will reduce Chrome market share too when other browsers refuse to deprecate the features uBlock Origin needs. Still not enough punishment for them.
The problem is this: Google cloud team probably want that chrome browser has more extensions, that extensions can control network flow (security, monitoring, etc.), and that it is easy to hot fix. On the other hand, Google ads team does not like extensions at all: especially if they can be used to block ads. Ads team has more $$ while cloud team are fighting hard to become relevant.
I understand but it doesn't excuse the fact they are using their market power to kill ad blockers and make our lives on the web infinitely worse. They shouldn't be able to just get away with it, we need to call them out every single time.
The true leverage comes from increasing the relevance of Firefox and Brave, eroding their market power as much as possible. Users should have ad blockers and the ads team should be able to do exactly nothing about it.
I knew this was coming. Google said that they're committed to allowing userscripts in MV3, but they haven't even started the implementation. They're still in the proposal phase.
MV3 was released in Chrome quite some time ago, and it is indeed incomplete. The question is not about releasing MV3, which has already been done, but rather about removing MV2. They keep postponing the removal of MV2, because MV3 is incomplete.
The entire meta-point of MV3 is, ostensibly for consumer protection, to prevent extension authors from dynamically executing code that has not been reviewed by Google’s review process, as well as from executing code synchronously to choose to block a network request. Of course, userscripts are dynamic code not delivered as part of the extension itself. And so are effective ad blockers - when one side of an arms race is fundamentally limited from running code, it becomes open season for the other. The conflict of interest left a foul taste in many people’s mouths.
According to my little research you can insert script tags, but you can only use the scripts which are bundled inside the extension. It's still not clear to me what prevents this script to download external script using AJAX which will execute whatever user wants (e.g. some cloud userscript service).
Also for power users it should not be a problem at all. Just create your own extension which is literally few simple files and put your userscripts inside that extension. Then load this extension from the chrome and voila.
> It's still not clear to me what prevents this script to download external script using AJAX which will execute whatever user wants
If you read the MV3 migration guide you’ll quickly realize why. CSP script-src is restricted to self, none, or localhost sources for all non-sandbox pages, content scripts included.
I don't think that's what I'm talking about. I'm talking about inserting a script from the extension which will then download another script from the external source and execute it. Once you've got access to the DOM, you're pretty much unstoppable.
Yes - I have done this in an MV3 extension. You can basically re-implement your own runtime and download the code and run it there instead of using eval/script tags.
It's very inefficient and it's a pain to write, but it is possible.
I suspect they will not approve extensions that do this if it becomes popular.
This has been so frustrating. My company has two Chrome extensions, one of which we've been able to migrate and are just finishing up, and one of which we are blocked on because we're waiting on a dependency to be sorted out.
Of course, we're not just on Chrome — we're also on Firefox. But our migrated extension doesn't work on Firefox, since they haven't fully figured out their transition plan. We're left with a gigantic mess that will be confusing to users (because our Chrome MV3 has significant changes to our freemium model, which made sense to implement during the manifest changeover). We'll have to explain to our FF users that they still have the old version, but the new version is only on Chrome. But for our other extension, everyone's on the old version. What a mess.
The issue is that when the MV3 transition was announced, we decided to revamp our freemium structure. We've now completed that for our MV3 extension, but that only runs on Chrome. Our Firefox version is still running the MV2 extension, which is perfectly functional but which uses our old freemium model. We are going to have to explain to our Firefox users why the freemium structure (free use on X websites forever) differs from the freemium structure described on our Chrome extension, website, etc. (free use on all websites for Y days).
The Chrome extensions team has been considerably more responsive to criticism since Simeon Vincent has become a Developer Advocate. It's important to see the perspective of developers who've been working with these APIs for years, and I'm glad that they are finally listening.
I'm not really sure I agree with this - I've been doing extension development for about 12 years now, and I think communication used to be fine.
Simply posting questions usually got meaningful feedback, and while the team certainly wasn't "taking advice" from the community at large, the manifest v2 space felt cohesive and generally well thought out.
Things worked. Documentation was decent. Compatibility problems between Firefox/Chrome were small and documented. It was still possible to load extensions outside the stores. Extensions could do genuinely powerful things.
Manifest v3... has been a complete fucking disgrace (and I say that as someone who was really, really trying to give Google the benefit of the doubt here early on, and someone who has personally ported my organization's extensions to MV3).
It's poorly documented (all sorts of things in the docs are half-assed, scattered links to mv2 only pages, dead/broken links in the pages, docs that contradict other docs, completely undocumented features and capabilities, bad examples, examples that no longer build, etc).
Basic features are literally not functional. We STILL to this day have repeated complaints from customers about the extension "dying" or "it stopped working" which I can fucking promise is this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=127115...
Which has been closed and opened several times (currently closed and is absolutely still happening). I still see this at least once a week in development. The service worker simply fucks off and stops doing anything at all (sitting there with "inactive" despite sending messages to it, or clicking the browser action).
Permissions are still a freaking disgrace - trying to play nice with the permissions APIs gets your extension relegated way down the list. Extensions which just request "all_urls" get put right at the top of the extensions list when a user clicks the extensions menu, while those that properly ask for the active_tab permission get shoved way down and have a "access requested" tag in bold that actually seems scarier to users than the extensions that just fucking declare all_urls.
Optional permissions, meanwhile, don't actually go away when you release them in chrome (why even have the fucking function call?) so you can't meaningfully display permissions status to users without tracking state yourself. And you sure as hell can't count on the state of a permission to indicate user preference on whether a feature should be active. Again - have to do all the tracking manually.
Basically - The chromium team is fucking up HARD here, in my opinion. It's really starting to feel like the decent developers are gone (and I know a lot of them are) and the result is now the same as IE used to be - the browser is just a political tool to control competition. There's little cohesion, features & flows are broken at random and with no documentation. Issues are triaged superficially and then closed instead of resolved. Developers are ridiculed by the team for posting questions (jesus some of the responses around questions for declarativeNetRequest are fucking bad - especially given the shoddy state of the docs), or simply ignored.
I'm pretty torn - I actually think the Edge port of chromium is better than chromium at this point - and if you'd told me 10 years ago that I would end up saying MS has a better browser, I would have laughed in your face.
Meanwhile FF is just limping along, and Safari is absolutely neglected because apple makes all their money in the app store, so it's in their interests to have a shoddy browser from a feature perspective (they still do good work on performance and battery usage, at least).
---
Long rant aside - I'm very disappointed in MV3. I tried hard to play along, and it's shite.
> Safari is absolutely neglected because apple makes all their money in the app store, so it's in their interests to have a shoddy browser from a feature perspective
This is a strange take as far as extensions are concerned, because last year iOS Safari introduced extension support, something that Android Chrome still doesn't have. And Apple does sell Safari extensions in the App Store, so extension development is in their interests.
It was just last year that Safari introduced extension support at all (at least on the shared webext api set)
Chrome first released them in 2009, version 4 (happened to still be on webkit then, too - so same rendering engine as safari). The space is 13 years old.
And even then... the supported api set is fairly minimal.
Combo that with the xcode lock in and... Apple still gets a solid failing grade from me.
> It was just last year that Safari introduced extension support at all (at least on the shared webext api set)
This is totally false. Safari Mac has had extension support since 2010.
Safari has gone through a few different extension formats: safariextz, app extensions, web extensions. But Chrome and Firefox have also gone through a few different extension formats.
Let me get this straight: google is removing support for blocking webRequest API, but keeping support for non-blocking webRequest API? How is this supposed to benefit privacy if the non-blocking API is still supported?
The "blocking" and "non-blocking" APIs do completely different things.
With the old API (webRequest), Chrome calls an extension's event handlers before every network request, and uses the result of the handler to decide whether to filter the request. This requires Chrome itself to block
With the new API (declarativeNetRequest), an extension sends a list of rules (i.e. URL patterns) to Chrome, and each rule specifies a static instruction that says how requests matching that pattern should be handled (for instance, being blocked, upgraded from HTTP to HTTPS, or redirected). So Chrome can use its own optimized lookup procedure and doesn't have to block waiting for extension code to complete, which might take arbitrarily long.
The privacy advantage is that the extension can tell Chrome how to handle network requests (in a much more limited way than before) but can't actually gain any information about what requests the user is making. But that's only part of the justification. The Chrome developers have stated in the past that they believe slow extensions using the old webRequest API are causing general browser performance problems (by doing lots of blocking computation on every request) and making it seem like it was Chrome's fault.
But don't they keep the original webRequest api in a way where it does not block and where an extension can observer all the traffice, do all the spying, but just cannot block requests?
The extension would need both the all_urls and webRequest permissions to do this, since you can only spy on requests to origins your extension has a host permission for. The review team discourages all_urls permissions and scrutinizes them more, so theoretically getting a spy onto the store with the right permission combo is hard. If you trust the review team.
Note that these regulations were established for MV2, and MV3 doesn't do anything new to address this. So there's still no benefit to MV3 on this topic. As far as I can tell, and I work with these APIs for a living, the privacy claims of MV3 are bogus.
The whole "Manifest V3" (what an opaque name --- again, likely a deliberate choice) push was ostensibly about privacy and security, but they're just excuses to further Google's control.
Says all you need to know. They are going to shove this down people's throats, whether they like it or not. Maybe not now, but it's coming. It's kind of disgusting how they talk about this change so matter of fact, as if Chrome is the only choice that people have.
I won't make as strong a claim that they've lobbied developers to make sites Chrome-only, but they've created a lot of tools for developers to check how performant their website is and how SEO friendly it is. Most of the time that's based on Google's metrics which work best on Google's browser and search.
For an example, see any discussion on Chrome-only non-standards like hardware APIs where people are convinced they are standards and all other browsers are holding the web back.
Their entire web.dev site is nothing but Chrome propaganda machine that frequently posts about Chrome-only tech or APIs without mentioning they are Chrome-only and possibly never have the chance of becoming cross-browser (web transport comes to mind as a recent example: shipped in Chrome, its status is literally "some ideas scribbled on a napkin")
booo..... "but muh brave wont be supporting it"....
the way to signal google that they are not doing a good thing is by replacing chrome/chromium with firefox. switching from chrome to opera/brave is doing the same thing.
sure, firefox is not helping their cause because of their CEO salivating at google revenue but even then, they have committed to supporting UBO, something that goes on to say a lot more about the ethics behind firefox as opposed to chrome
This is for Manifest V2 (browser extension API that has been generating a lot of debate) and not some Mountain View office footprint expansion like I mistakenly thought out of context.
Translation: We already accomplished our goal of killing (efficient, effective) ad blockers and we really don't feel like doing the rest of the work. Have fun with the results!
I suppose Google gets a tiny bit of credit for not jamming MV3 through and leaving developers with the bill, but given the state of things, who has any confidence in what the future of browser extensions holds?