[ffsm8]

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.

[tgsovlerkhgsel]

Chrome officially supports Manifest V2 extensions until at least June 2025, hidden behind an enterprise flag: https://developer.chrome.com/docs/extensions/develop/migrate...

I expect Brave to easily support it until then and then drop it very quickly as you described.

[b112]

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.

[Barrin92]

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

[b112]

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.

[jay_kyburz]

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.

[ffsm8]

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.

[jay_kyburz]

I imaged you would use both.

[mindcrash]

Brave supports uBO blocklists OOTB, no extension needed.

So even when they have to say farewell to Manifest v2 it really doesn't matter, at least in case of privacy (and for some medical) protection.

[soundnote]

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.

[SllX]

This is good info to keep in my back pocket. Thanks!

[paradox460]

As does Vivaldi

[kolanos]

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.

[lillecarl]

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?

[fuzzy2]

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.

[notpushkin]

Why can’t forks just maintain an independent implementation afterwards?

[ffsm8]

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

[Zak]

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.

[justinclift]

> ... and Google's technical excuses for removing it are disingenuous.

That's been the default assumption of pretty much everyone anyway.

[account42]

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.

[SirMaster]

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.

If not today maybe soon...

[bawolff]

Because these aren't really independent browsers but reskins.

Being independent of google requires actually doing the work and not just copying google.

[notpushkin]

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