5 ms·

If it's chromium based, they will need to remove manifest v2 at some point to stay close to the upstream version.

SllX 2y ago
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.
- ffsm8 2y ago
  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.
  - lillecarl 2y ago
    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 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...
  - tgsovlerkhgsel 2y ago
    Chrome officially supports Manifest V2 extensions until at least June 2025, hidden behind an enterprise flag: https://developer.chrome.com/docs/extensions/develop/migrate/mv2-deprecation-timeline#june_2025_chrome_mv2_deprecation_enterprise_rollout 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 2y ago
      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.
      - jay_kyburz 2y ago
        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 2y ago
        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 2y ago
        I imaged you would use both.
      - Barrin92 2y ago
        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
  - kolanos 2y ago
    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.
  - mindcrash 2y ago
    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.
    - SllX 2y ago
      This is good info to keep in my back pocket. Thanks!
    - paradox460 2y ago
      As does Vivaldi
    - soundnote 2y ago
      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.
jeroenhd 2y ago
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.

SllX 2y ago

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.

ffsm8 2y ago
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.
- lillecarl 2y ago
  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 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...
- tgsovlerkhgsel 2y ago
  Chrome officially supports Manifest V2 extensions until at least June 2025, hidden behind an enterprise flag: https://developer.chrome.com/docs/extensions/develop/migrate/mv2-deprecation-timeline#june_2025_chrome_mv2_deprecation_enterprise_rollout 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 2y ago
    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.
    - jay_kyburz 2y ago
      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 2y ago
        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 2y ago
        I imaged you would use both.
    - Barrin92 2y ago
      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
- kolanos 2y ago
  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.
- mindcrash 2y ago
  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.
  - SllX 2y ago
    This is good info to keep in my back pocket. Thanks!
  - paradox460 2y ago
    As does Vivaldi
  - soundnote 2y ago
    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.

jeroenhd 2y ago

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.