Possibly in Arc, although Brave also continues to support Manifest v2 so it’s possible it will continue to persist in some subset of Chromium-based browsers and as I said, it ships with the browser and is installed by default; but Orion is not Chromium-based.
Brave supports it right now, which is 2 months after it's been removed upstream.
I strongly suspect they're gonna drop support as soon as the first bigger merge issue happens along with a heartfelt blog that "they did they everything to support it, but it was just too much for the resources available to them"
I doubt it's gonna take more then 1-2 years (December 2027) for this to happen, but we will see.
You know, Google's really playing with fire here. There are enough browser companies running Chrome underneath, to more than equal Google's commitment.
That is, if those companies choose.
If even 80% of them wanted to fork? Not a biggie. And they could still cherry pick commits from the alt fork.
I think you might be underestimating the scope of work that happens on chromium a tad, from Github's "pulse" feature:
"Excluding merges, 684 authors have pushed 3,139 commits to main and 3,866 commits to all branches. On main, 14,924 files have changed and there have been 740,516 additions and 172,682 deletions."
That's stats from last week. Last year Google apparently was responsible for about 95% of contributions. Other than Microsoft (which has the same bad incentives as Google) none of the alt-chromium browser companies has like, 5% of the engineers to maintain a real alternative
Yes, but as I said they can merge in changes. Apparently more than I thought, but still, they can.
Opera has pinch-zoom text-reflow in a chromium backend, and that seems to be substantial, and yet it is (on purpose) kept out of mainline chrome. So they do loads of tracking/merging too.
The scope of work to do a few small features on top of chrome wouldn't be a biggie, compared to the entire project.
How hard would it be to "wrap" the browser in a ublock like shell, so that all network requests are filtered through a firewall before they even reach the chrome application layer.
It might be easier to maintain than an actual extension interface with hooks thought the code.
I don't think you'd need manifest V2 for such a rudimenty logic.
The reason why ublock origin is so powerful is because it works with the DOM/not at the network level and can use heuristics to determine wherever something is a advertisement or not.
In addition, since their adblocker isn't an extension and doesn't care about extension APIs, they can do things even Manifest v2 Chrome extensions can't. For example, full-fat uBO can't do CNAME uncloaking on Chromium due to API limitations, but can do it on Firefox which has the APIs. Brave is Chromium-based, but since Shields isn't an extension they've built CNAME uncloaking into it.
This is arguably the most compelling reason for people to switch to Brave. If there are smart people over there, they'll make a concerted effort to keep Manifest v2 in their fork.
I don't understand or know alot about extensions, but what is so incredibly impossible about adding new capabilities to manifestv3? It's a manifest describing what the addon wants to do and some UX to allow it right?
It’s not really about the manifest. It’s about the APIs available to extension programmers. Chrome has made the "webRequestBlocking" API unavailable and that’s what’s affecting adblockers. Chrome will eventually remove the code supporting this API, and it is not feasible for downstream to make it available anyway.
They could, theoretically. But just imagine what that actually means. Unless you cease merging upstream/the project you've forked, you'll have to resolve all conflicts caused by this divergence.
And that's a lot of work for a multi million LOC project, unless the architecture is specifically made to support such extensions... which isn't the case here.
And freezing your merges indefinitely isn't really viable either for a browser
A quick look at the code gives me the impression that webRequestBlocking is a fairly trivial modification to webRequest, and they seem to be keeping the latter. This leads me to two conclusions: it wouldn't be terribly hard for a fork maintainer to keep webRequestBlocking, and Google's technical excuses for removing it are disingenuous.
That may be true now but will it still be true when Google next refactors their request code under the assumption that no requirements for a webRequestBlocking API exist.
So go make an LLM manage the fork or something. Everyone keeps telling me they are amazing at code these days. Surely it can do a task like that if that's all it's doing all day.
The codebase is huge, sure, but the particular feature is relatively small and (as I assume and as verified by another poster) quite easy to implement: https://news.ycombinator.com/item?id=43204603
I think if a bunch of Chromium forks come together, they can maintain v2 support for quite a while. A fork maintained by a combination of Brave, Opera, Vivaldi, and maybe some of those startup-based browsers can probably keep the most important APIs running for quite some time.
At some point the issues will become too difficult to fix, but none of these companies need to be doing it alone. Adding a separate upstream with some "fuck off Google" fixes for them to base their proprietary browser on seems like a smart thing to do.
