Two questions I haven't seen addressed by any coverage of this change:
1. Will the ultimate removal of Manifest V2 support affect other Chromium-based browsers, or only Chrome itself?
If the support for Manifest V2 isn't removed upstream in Chromium, but only disabled in Chrome, then I would expect that we will end up in a world where other browsers (e.g. Edge, Brave, Opera) continue to allow the installation of Manifest V2 extensions, esp. from their own first-party verified-extension hosting platforms. So even if the Chrome Web Store also ceases to host Manifest V2 extensions, users of these other Chromium-based browsers could still get uBlock Origin from "Edge Add-ons" or "Opera Addons" etc.
2. Would it be possible for some random developer to put in a PR to the upstream Chromium project, to introduce one or more Manifest V3 capabilities (new strings for the manifest.json "permissions" key) that, when added, would allow the extension to do all the stuff that Manifest V2 let extensions do by default, that uBO and others depend on: increased request-filter list size, async periodic network data-file updates, etc? Would such a PR have any chance of being accepted?
My own guess is that such a PR wouldn't be accepted, because I get the impression that the nominal goal of Manifest V3 is to allow V3 extensions to run under a streamlined extension "runtime" that has fewer hook-points into the browser runtime, and so fewer places where the browser runtime must call back to the extension runtime; where adding such capabilities would require adding all these additional hook-points and callbacks back in, which would defeat the purpose. Correct me if I'm wrong!
I would also guess that even if such a PR were accepted, Chrome would still disable the use of those capabilities downstream, and also reject any extension that used them from the Chrome Web Store. So at best, such a change would just mean that uBO and friends wouldn't be stuck as "legacy" Manifest V2 extensions, but could instead just be "modern" Manifest V3 extensions with a few capabilities that Chrome and only Chrome forcibly rejects.
1. Brave, Vivaldi, and Opera have all announced they'd maintain support for Mv2 past Google's deprecation date [1].
2. Your guess is correct - one of Google's stated motivations is to make the extension review process easier and less error-prone; having a way to opt-out would be counterproductive in that regard. I strongly doubt they'd accept the PR upstream; there is a chance other players could maintain patches to modify Mv3 but the effort of designing and implementing a new spec around the Mv3 spec and convincing extensions to maintain yet another platform means this is unlikely to happen in practice. Keeping Mv2 around is a more reasonable approach (and one that is compatible with Firefox, as well).
Will you be working together with Vivaldi and Opera to maintain the fork of MV2's request interception, or will we have multiple independent implementations?
Nothing coordinated so far, but keep in mind Mv2 code will still exist behind a policy flag in Chromium until at least June 2025; there's still quite some time.
> there is a chance other players could maintain patches to modify Mv3 but the effort of designing and implementing a new spec around the Mv3 spec and convincing extensions to maintain yet another platform means this is unlikely to happen in practice.
The design has already been completed, in that mozilla has already done this in their implementation of manifest v3. The difficulty of convincing extension developers to support it should thus be no more difficult than convincing them to ship a firefox version of their extension.
> Keeping Mv2 around is a more reasonable approach (and one that is compatible with Firefox, as well).
This isn't a long term solution. Brave for example has only committed to maintaining mv2 support as long as chrome continues to support it internally. If chrome removes it, the work of continuing to support it would become untenable.
so in summary, all the clonium browsers depend on the company who is currently in the process of removing mv2 to not remove mv2 in their repo. good luck with that
Vivaldi and Brave are going to maintain the code so at least uBlock Origin can work. Nobody knows how this will play out as the forks won’t want to stray faraway from the chromium code as that would add a lot of overhead.
I tried a bunch of the forks, didn’t like Vivaldi, don’t like some of Braves crap, and won’t use the Chinese browser Opera.
Ended up moving our family back to Firefox.
I miss chromium’s better profile management and the app as a window. Rest of the family don’t miss any of those. Other than that happy with Firefox.
I've been using containers for a while, and have to say that UX wise, it needs work, it's too easy to inadvertently leave a container tab, and it's easy to get them confused.
The effect is "invisible", so there's no warning sign when you've done something wrong. My use-case is managing instagram profiles which periodically log you out, so if you forget and log in with the wrong one it's kind of game over.
In sum, it's too wonky for the general masses. Sure, Mozilla could add it just for the experts but that doesn't seem to be their approach which I can respect. After all it's not hard for an "expert" to get containers running.
One reason Google wants to remove V2 support is to make implementation changes that V2 currently prevents. This means that a Chromium fork that preserves V2 support will likely have to diverge further and further from Chromium over time (or rather, Chromium will diverge).
Gecko is not worse, though it used to be worse before Electrolysis landed. It's just that Mozilla Corp is mostly kept alive by Google so might as well remove the indirection and go straight to the browser that Google maintains
How much money do you reckon it costs for just the Firefox browser?
I know Mozilla waste a lot of effort on projects like Firefox OS, the Firefox mobile, politics, etc. But the actual browser it's self and it's hosting?
I just wonder if they end up dropping Manifest V2, if a patron model would work to maintain a fork properly...
I've heard this said a few times but no one has ever supplied any reputable source other than fanciful speculation. It's become such a meme at this point that I'm pretty sure it's just harmful disinformation.
Maybe I succumbed to that meme, I honestly don’t remember. I’m not in favor of what Google is doing. But I’m sure the implementation divergence will happen if V2 support is dropped. It pretty much always does once a public API is removed.
Does Google have veto power over what goes into Chromium?
I had always assumed the relationship between Chromium and Google was akin to the relationship between Webkit and Apple, or between any ASF-donated project and its corporate originator: a community-owned (and several-major-corporate-stakeholders sponsored) open-source project upstream, with a corporate closed-source "living patchset" project sitting downstream of it; where the corporate devs try to push as much as possible upstream, to keep the patchset they must maintain downstream as thin as possible; but where it isn't up to the corporate devs whether the upstream "steering committee" accepts the corporate work upstream.
But I guess this isn't true; per Wikipedia:
> However, in terms of governance, the Chromium projects are not independent entities; Google retains firm control of them.
Which is just bizarre to me, given the following sentence on that page:
> The Chromium browser codebase is widely used, so others have made important contributions, most notably Microsoft, Igalia, Yandex, Intel, Samsung, LG, Opera, Vivaldi Technologies, and Brave. Some employees of these companies also have @chromium.org email addresses.
You'd think these other companies wouldn't stand for Google having unilateral control over a project they're so dependent on! But I guess, as large corporations, they can always express their true concerns through more... corporate politick-y means.
As far as Microsoft is concerned, they're large enough to fork Chromium if they wanted to, just like how Google forked Webkit into Blink. Every other organization that ships a Chromium-based browser is fully at Google's mercy; Google holds the keys to the kingdom: https://chromium.googlesource.com/chromium/src/
Microsoft maintained their own browser engine for decades, they had good reasons to drop them - I'm not even sure if there would be enough staff left there to actually be able to keep up with Chromium in a fork.
1. Will the ultimate removal of Manifest V2 support affect other Chromium-based browsers, or only Chrome itself?
If the support for Manifest V2 isn't removed upstream in Chromium, but only disabled in Chrome, then I would expect that we will end up in a world where other browsers (e.g. Edge, Brave, Opera) continue to allow the installation of Manifest V2 extensions, esp. from their own first-party verified-extension hosting platforms. So even if the Chrome Web Store also ceases to host Manifest V2 extensions, users of these other Chromium-based browsers could still get uBlock Origin from "Edge Add-ons" or "Opera Addons" etc.
2. Would it be possible for some random developer to put in a PR to the upstream Chromium project, to introduce one or more Manifest V3 capabilities (new strings for the manifest.json "permissions" key) that, when added, would allow the extension to do all the stuff that Manifest V2 let extensions do by default, that uBO and others depend on: increased request-filter list size, async periodic network data-file updates, etc? Would such a PR have any chance of being accepted?
My own guess is that such a PR wouldn't be accepted, because I get the impression that the nominal goal of Manifest V3 is to allow V3 extensions to run under a streamlined extension "runtime" that has fewer hook-points into the browser runtime, and so fewer places where the browser runtime must call back to the extension runtime; where adding such capabilities would require adding all these additional hook-points and callbacks back in, which would defeat the purpose. Correct me if I'm wrong!
I would also guess that even if such a PR were accepted, Chrome would still disable the use of those capabilities downstream, and also reject any extension that used them from the Chrome Web Store. So at best, such a change would just mean that uBO and friends wouldn't be stuck as "legacy" Manifest V2 extensions, but could instead just be "modern" Manifest V3 extensions with a few capabilities that Chrome and only Chrome forcibly rejects.