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.

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

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

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.

If not today maybe soon...

Because these aren't really independent browsers but reskins.

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

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