3 ms·

This is just kicking the can down the road. The bigger question is how the Chromium forks are going to respond long-term. I suspect the APIs enabling ad blocki

This is just kicking the can down the road. The bigger question is how the Chromium forks are going to respond long-term. I suspect the APIs enabling ad blocking are only going to get more clamped down requiring additional work for forks.

tech234a 2y ago
Policy-installed extensions can continue to use the WebRequest blocking APIs on Manifest V3 [1], so I would expect that the underlying code for the API would remain available for forks to use. [1] https://developer.chrome.com/docs/extensions/reference/api/webRequest https://developer.chrome.com/docs/extensions/reference/api/w...
IronRod 2y ago
Brave has committed to do what they can as long as they can. But unsure how long and what that really turns out to be. https://brave.com/blog/brave-shields-manifest-v3/ https://brave.com/blog/brave-shields-manifest-v3/
- mindcrash 2y ago
  Like I said before, Brave even has a better solution because it has a uBlock compatible ad blocker _built in straight into its core_ (but its disabled by default). Same block lists, same safety assurances. Although I still use Firefox with uBlock as my daily driver at home, Brave with block lists and Shields is right next to it (and I use it as my daily driver at work). It works pretty damn well!
- sebazzz 2y ago
  That is easy talking from Brave as long as it is still a config flag, then after a compile-time flag. Once the internal APIs for MV2 or where MV2 get removed or changed it becomes very difficult to maintain. Never mind the possible security issues you introduce, but won’t get so quickly discovered, because Brave is a smaller target.
  - BrendanEich 2y ago
    Maybe you have inside info, but last we knew, Google needs internals for webRequest for its enterprise Chrome customers. I think this is not the dire situation your words convey.
  - Spivak 2y ago
    I mean this isn't rocket surgery, carrying a patch set isn't as hard as this thread is making it out to be. Your Linux distro right now is carrying thousands.

tech234a 2y ago

Policy-installed extensions can continue to use the WebRequest blocking APIs on Manifest V3 [1], so I would expect that the underlying code for the API would remain available for forks to use. [1] https://developer.chrome.com/docs/extensions/reference/api/webRequest https://developer.chrome.com/docs/extensions/reference/api/w...

IronRod 2y ago

Brave has committed to do what they can as long as they can. But unsure how long and what that really turns out to be. https://brave.com/blog/brave-shields-manifest-v3/ https://brave.com/blog/brave-shields-manifest-v3/

mindcrash 2y ago
Like I said before, Brave even has a better solution because it has a uBlock compatible ad blocker _built in straight into its core_ (but its disabled by default). Same block lists, same safety assurances. Although I still use Firefox with uBlock as my daily driver at home, Brave with block lists and Shields is right next to it (and I use it as my daily driver at work). It works pretty damn well!
sebazzz 2y ago
That is easy talking from Brave as long as it is still a config flag, then after a compile-time flag. Once the internal APIs for MV2 or where MV2 get removed or changed it becomes very difficult to maintain. Never mind the possible security issues you introduce, but won’t get so quickly discovered, because Brave is a smaller target.
- BrendanEich 2y ago
  Maybe you have inside info, but last we knew, Google needs internals for webRequest for its enterprise Chrome customers. I think this is not the dire situation your words convey.
- Spivak 2y ago
  I mean this isn't rocket surgery, carrying a patch set isn't as hard as this thread is making it out to be. Your Linux distro right now is carrying thousands.