3 ms·

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

by fuzzy2 2y ago

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 2y ago
Why can’t forks just maintain an independent implementation afterwards?
- ffsm8 2y ago
  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 2y ago
    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 2y ago
      > ... and Google's technical excuses for removing it are disingenuous. That's been the default assumption of pretty much everyone anyway.
    - account42 2y ago
      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 2y ago
    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 2y ago
  Because these aren't really independent browsers but reskins. Being independent of google requires actually doing the work and not just copying google.
  - notpushkin 2y ago
    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 https://news.ycombinator.com/item?id=43204603

by fuzzy2 2y ago

notpushkin 2y ago

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

ffsm8 2y ago
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 2y ago
  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 2y ago
    > ... and Google's technical excuses for removing it are disingenuous. That's been the default assumption of pretty much everyone anyway.
  - account42 2y ago
    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 2y ago
  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 2y ago
Because these aren't really independent browsers but reskins. Being independent of google requires actually doing the work and not just copying google.
- notpushkin 2y ago
  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 https://news.ycombinator.com/item?id=43204603