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!
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?
I just wrote a quick script to survey extensions featured on the Chrome Web Store.
Of the 1200 checked so far:
Manifest v2: 872
Manifest v3: 328
They'd basically be breaking almost 2/3 of extensions.
EDIT: Just noticed 9 out of 12 of Google's own extensions are still on manifest v2 as well: https://chrome.google.com/webstore/category/collection/by_ch...
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.
[1]: https://chrome-stats.com/manifest-v3-migration
[2]: https://www.debugbear.com/blog/counting-chrome-extensions
Back in my day attaching Google’s name to a product was a positive development. Remember GMail?
“Unmitigated shitshow” is the only thing that comes to mind today.
What tech giveth, tech taketh away.
This is so true. They even closed down their IoT core for pennies.
Google = unreliable as business partners and more shitty every day anyway.
It's almost like they have an incorrect corporate reward function, that their employees are then optimizing...
> What tech giveth, tech taketh away.
Honestly, I would say it's more "what tech giveth, greed taketh away."
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.
Our solution has been to uninstall Chrome. Firefox, and when unavoidable, DuckDuckGo's private browser, are doing fine.
Firefox is gonna do MV3 too except keep the request intercepting API so it’s not terribly different.
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.
Isn't one of the requirements to be featured using Manifest v3?
https://developer.chrome.com/docs/webstore/best_practices/
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.
https://developer.chrome.com/docs/webstore/discovery/#featur...
> Chrome team members manually evaluate each extension before it receives the badge, paying special attention to the following:
> 1. Adherence to Chrome Web Store’s best practices
I guess it’s “evaluated” on adherence, rather than it being a hard requirement
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.
> The deprecation timeline is too aggressive
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.
> I suppose Google gets a tiny bit of credit for not jamming MV3 through and leaving developers with the bill
They will try again in a year, and there will be less opposition (because people get tired of fighting etc.), and this will happen
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).
What a weird thing to say.
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 was writing an extension a few weeks ago. I decided to go with MV3.
Most of the examples and documentation said something like "this has been copied from the MV2 documents or example. It might not work." It was awful.
I felt MV3 is really about limiting what the extensions can do.
I ended up having it Firefox only and MV2. Probably works in Chrome too, but I wasn't going to waste time on it since it was about to be removed.
> 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.
[1]: https://github.com/b0o/aws-favicons-webextension
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.
All of Google's documentations are awful.
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.
They don't care about developers.
They put in quite some effort into writing the docs but then they often leave them to rot. Broken links and invalid code.
You'd have thought that a company the size of Google would have their public documentation problem totally solved by now.
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 :)
Hey! What things related to xml are you working on? I for one went through the signing and stuff and it was pretty rough going.
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.
1: https://github.com/enketo
2: https://github.com/getodk
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.
FYI Firefox is ditching MV2 too, they are keeping web request blocking but they will deprecate v2
> 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.
https://blog.mozilla.org/addons/2022/10/31/begin-your-mv3-mi...
https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-fi...
I guess they are following Chrome migration plan by delaying the inevitable
I don't think that says anything about concrete plans for ditching MV2 yet?
Yeah, it's in the nightly and going to GA Jan 23 according to the latest blog post on it.
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.
> Still not enough punishment for them.
Force them all to live as Winston Smith in rooms with wall sized screens that deliver unblockable ads and monitor their every action?
ie. To eat their own dogfood.
Don't forget the high pitched noise when they try to close their eyes.
New on Wraith Babes, millions watched her glide through the Hot Shot curtain of dreams... ...Insufficent funds to skip...
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.
Thus the shitshow.
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.
Your take on this is exactly correct.
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.
https://github.com/w3c/webextensions/issues/279
They didn’t commit to being in the first release of MV3. I expect MV3 to be incomplete when first released in chrome.
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.
You can't insert tag into webpage? I'm confused.
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.
Quite literally yes. It would've killed GreaseMonkey userscripts and such
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.
https://developer.chrome.com/docs/extensions/mv3/mv3-migrati...
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.
No, CSP doesn’t allow you to download scripts from an external source. That’s the point of the CSP.
Since one of the parent comments mentioned AJAX, I'll add that you'll also be prevented from eval'ing that payload.
Yes, I should have been more clear: CSP doesn’t allow you to download an external script and execute it, which requires unsafe-eval.
Sounds like your exception will need to become a language interpreter itself.
Does manifest v3 support wasm?
Time to package a JavaScript interpreter into wasm and run it within the extension.
You still can just write your userscript as an extension. I just checked - it works. I inserted script into HN and did some stuff.
I never said you can’t.
Can you pass data between script and extension? Implementing JS or lua should be possible.
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.
I thought Firefox had no MV3 plans. Why does that extension require a transition?
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).
Locking the message so nobody can reply is a nice touch.
The removed the dislike button after some exec video of google got so many dislike.
That was the video where Susan Wojcicki received a freedom of speech award from her mom
That's the Google way(tm)
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.
Vincent has been in that position for 4 years, so I'm not sure what you think has changed.
Before that we didn't have anyone to contact, and the Chrome extensions team definitely did not react to feedback in any meaningful way.
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.
It's a separate permission, I believe.
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.
Previous Google Chrome extensions Manifest V2 shutoff update thread: https://news.ycombinator.com/item?id=33012057
This is a huge relief. The lack of Offscreen Documents API has been a huge hurdle for migrating to MV3 and has caused numerous headaches.
Some of the most interesting announcements are made late on Fridays.
> This conversation is locked
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.
They've already lobbied plenty of web developers into making sites Chrome-only. It certainly shows how powerful their propaganda is.
>They've already lobbied plenty of web developers into making sites Chrome-only
No they didn't, why do you lie like that?
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.
The web performance metrics absolutely are not specific to Chrome, what makes you think that?
>Most of the time that's based on Google's metrics which work best on Google's browser
And which ones are that? Time to first byte, first content paint, render blocking resources?
Yes they did.
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")
The story:
They announced mv2 will phase out.
Their initial plan for mv3 was to cripple remote code execution and network requests intercept api for their own good.
They didn't anticipate this much backlash from the community.
Now they've to reintroduce those capabilities making it same to mv2 :|
Circus.
Related. Others?
Feel the power of the Manifest v3 - https://news.ycombinator.com/item?id=33063619 - Oct 2022 (274 comments)
Google postpones MV2 shutoff in Chrome stable to June 2023 - https://news.ycombinator.com/item?id=33012057 - Sept 2022 (283 comments)
Manifest V3: The Ghostery Perspective (2021) - https://news.ycombinator.com/item?id=32983565 - Sept 2022 (5 comments)
Manifest V3, webRequest, and ad blockers - https://news.ycombinator.com/item?id=32950199 - Sept 2022 (153 comments)
uBlock Origin Lite: Description - https://news.ycombinator.com/item?id=32911640 - Sept 2022 (148 comments)
Proxy Chrome extensions are not going to be usable in MV3 - https://news.ycombinator.com/item?id=32899846 - Sept 2022 (204 comments)
Ad blockers struggle under Chrome's new rules - https://news.ycombinator.com/item?id=32764304 - Sept 2022 (3 comments)
“UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3 - https://news.ycombinator.com/item?id=32754274 - Sept 2022 (255 comments)
AdGuard publishes the first ad blocker built on Manifest V3 - https://news.ycombinator.com/item?id=32648131 - Aug 2022 (360 comments)
Cannot read clipboard from service worker in a MV3 chrome extension (2020) - https://news.ycombinator.com/item?id=32622739 - Aug 2022 (51 comments)
Tor Project – 'We are concerned about Google's plan to retire Manifest v2' - https://news.ycombinator.com/item?id=32608847 - Aug 2022 (4 comments)
Chrome extension Manifest V3 migration tracker - https://news.ycombinator.com/item?id=31494944 - May 2022 (6 comments)
Manifest v3 in Firefox: Recap and Next Steps - https://news.ycombinator.com/item?id=31425256 - May 2022 (168 comments)
Ask HN: Will you keep using Chrome when manifest-v2 is sunset? - https://news.ycombinator.com/item?id=30589773 - March 2022 (5 comments)
Google’s Manifest V3 still hurts privacy, security, and innovation - https://news.ycombinator.com/item?id=29555673 - Dec 2021 (2 comments)
Google Nukes Ad-Blockers–Manifest V3 Is Coming - https://news.ycombinator.com/item?id=29522952 - Dec 2021 (6 comments)
PSA: uBlock/AdBlocks on Chrome to lose function thanks to Manifestv3 - https://news.ycombinator.com/item?id=29521258 - Dec 2021 (315 comments)
Chrome users beware: Manifest v3 is deceitful and threatening - https://news.ycombinator.com/item?id=29502439 - Dec 2021 (375 comments)
Chrome phasing out Manifest v2 support from Jan 2022 - https://news.ycombinator.com/item?id=29410104 - Dec 2021 (33 comments)
Google sets burial date for legacy Chrome Extensions, fears for ad-blockers grow - https://news.ycombinator.com/item?id=28680033 - Sept 2021 (386 comments)
Manifest V2 Support Timeline - https://news.ycombinator.com/item?id=28645250 - Sept 2021 (2 comments)
Manifest v3 Update - https://news.ycombinator.com/item?id=27305127 - May 2021 (93 comments)
Microsoft Will Adopt Google Chrome's Controversial Manifest V3 in Edge - https://news.ycombinator.com/item?id=25445823 - Dec 2020 (4 comments)
Manifest V3 now available on M88 Beta - https://news.ycombinator.com/item?id=25361535 - Dec 2020 (138 comments)
Manifest V3 changes are now available to test in Microsoft Edge - https://news.ycombinator.com/item?id=24780055 - Oct 2020 (36 comments)
Google Begins Testing Extension Manifest V3 in Chrome Canary - https://news.ycombinator.com/item?id=21503049 - Nov 2019 (436 comments)
Mozilla’s Manifest v3 FAQ - https://news.ycombinator.com/item?id=20867720 - Sept 2019 (106 comments)
Chrome extension manifest v3 proposal: comment from uBlock Origin author - https://news.ycombinator.com/item?id=20050173 - May 2019 (279 comments)
Google to restrict modern ad blocking Chrome extensions to enterprise users - https://news.ycombinator.com/item?id=20044430 - May 2019 (877 comments)
Chrome Extension Manifest V3 Could End UBlock Origin for Chrome - https://news.ycombinator.com/item?id=18976409 - Jan 2019 (4 comments)
Chrome Extension Manifest V3 (draft) may end uBlock Origin - https://news.ycombinator.com/item?id=18971656 - Jan 2019 (3 comments)
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!