4 ms·

It'll be gone the moment upstream drops it. Maintaining this in a fork will be a lot of work. Fortunately it's still available even in Chrome for a while, but t

It'll be gone the moment upstream drops it. Maintaining this in a fork will be a lot of work. Fortunately it's still available even in Chrome for a while, but that's just an ultimatum

Timon3 2y ago
That's my expectation too, but it makes avoiding Chrome & Chromium unavoidable.
tzs 2y ago
Even if maintaining Manifest V2 is too much work after upstream drops it that doesn't necessarily mean that they just have to accept Manifest V3 as shipped in upstream. From what I've read there are two main problems with Manifest V3 when it comes to ad blocking. Problem #1. The webRequestBlocking permission is gone: > Note: As of Manifest V3, the "webRequestBlocking" permission is no longer available for most extensions. Consider "declarativeNetRequest", which enables use the declarativeNetRequest API. Aside from "webRequestBlocking", the webRequest API is unchanged and available for normal use. Policy installed extensions can continue to use "webRequestBlocking". That does not necessarily mean good ad blocking must break. Most people find the ad blockers on Safari to be fine, and Safari does not have that kind of blocking. It has long required the declarative rule kind of blocking. Some brief searching suggests that the rules for Chrome's declarative blocking are actually more powerful than Safari's. That brings us to the second Manifest V3 problem. Problem #2. The declarative rules only allows something like 30k rules. Apple found that such a low limit is not sufficient and raised it to 150k. I'd guess that maintaining a fork that just raises the limit in Chrome would not be a problem for the Chromium-based third party browsers. The big question would be whether the current 30k limit is there for technical reasons or for marketing reasons like not wanting ad blocking to be too effective. If it is a technical limit the forkers might also have to rewrite the rule processing engine which would likely be more than they would want to deal with. [1] https://developer.chrome.com/docs/extensions/reference/api/webRequest https://developer.chrome.com/docs/extensions/reference/api/w...
- wobfan 2y ago
  > The big question would be whether the current 30k limit is there for technical reasons or for marketing reasons like not wanting ad blocking to be too effective. If it is a technical limit the forkers might also have to rewrite the rule processing engine which would likely be more than they would want to deal with. It’s Google. The whole Manifest is there for marketing reasons. The whole browser even. Google doesn’t want us to have a nice browser because it benefits us. It benefits them. And this will continue. With V3 they already did the biggest cut down of af blocking in their browser. They will continue this path. Their main income is ads. They don’t care for anything else.
- Timon3 2y ago
  > That does not necessarily mean good ad blocking must break. Most people find the ad blockers on Safari to be fine, and Safari does not have that kind of blocking. It has long required the declarative rule kind of blocking. This presupposes that advertising platforms will not react to the changes to adblocking in any way, but I don't think that's realistic. The declarative rules can only be changed with updates to the extension (AFAIK, please correct me if I'm wrong). This means users can't block ads themselves (at least uBlock Origin Lite can't do it), and it will take between days to weeks until new block lists have propagated. Now, remember last year when YouTube started blocking adblockers? They changed their implementations sometimes multiple times per day, and after minutes to hours new blocklists were distributed that got around them. This won't be possible anymore with Manifest V3, so Google just has to update their adblock implementation often enough to finally get rid of them. And the same goes for other platforms. Once the majority of users is using browsers that only allow declarative blocking, more platforms will start updating more frequently.

It'll be gone the moment upstream drops it. Maintaining this in a fork will be a lot of work. Fortunately it's still available even in Chrome for a while, but that's just an ultimatum

Timon3 2y ago

That's my expectation too, but it makes avoiding Chrome & Chromium unavoidable.

tzs 2y ago

Even if maintaining Manifest V2 is too much work after upstream drops it that doesn't necessarily mean that they just have to accept Manifest V3 as shipped in upstream. From what I've read there are two main problems with Manifest V3 when it comes to ad blocking. Problem #1. The webRequestBlocking permission is gone: > Note: As of Manifest V3, the "webRequestBlocking" permission is no longer available for most extensions. Consider "declarativeNetRequest", which enables use the declarativeNetRequest API. Aside from "webRequestBlocking", the webRequest API is unchanged and available for normal use. Policy installed extensions can continue to use "webRequestBlocking". That does not necessarily mean good ad blocking must break. Most people find the ad blockers on Safari to be fine, and Safari does not have that kind of blocking. It has long required the declarative rule kind of blocking. Some brief searching suggests that the rules for Chrome's declarative blocking are actually more powerful than Safari's. That brings us to the second Manifest V3 problem. Problem #2. The declarative rules only allows something like 30k rules. Apple found that such a low limit is not sufficient and raised it to 150k. I'd guess that maintaining a fork that just raises the limit in Chrome would not be a problem for the Chromium-based third party browsers. The big question would be whether the current 30k limit is there for technical reasons or for marketing reasons like not wanting ad blocking to be too effective. If it is a technical limit the forkers might also have to rewrite the rule processing engine which would likely be more than they would want to deal with. [1] https://developer.chrome.com/docs/extensions/reference/api/webRequest https://developer.chrome.com/docs/extensions/reference/api/w...

wobfan 2y ago
> The big question would be whether the current 30k limit is there for technical reasons or for marketing reasons like not wanting ad blocking to be too effective. If it is a technical limit the forkers might also have to rewrite the rule processing engine which would likely be more than they would want to deal with. It’s Google. The whole Manifest is there for marketing reasons. The whole browser even. Google doesn’t want us to have a nice browser because it benefits us. It benefits them. And this will continue. With V3 they already did the biggest cut down of af blocking in their browser. They will continue this path. Their main income is ads. They don’t care for anything else.
Timon3 2y ago
> That does not necessarily mean good ad blocking must break. Most people find the ad blockers on Safari to be fine, and Safari does not have that kind of blocking. It has long required the declarative rule kind of blocking. This presupposes that advertising platforms will not react to the changes to adblocking in any way, but I don't think that's realistic. The declarative rules can only be changed with updates to the extension (AFAIK, please correct me if I'm wrong). This means users can't block ads themselves (at least uBlock Origin Lite can't do it), and it will take between days to weeks until new block lists have propagated. Now, remember last year when YouTube started blocking adblockers? They changed their implementations sometimes multiple times per day, and after minutes to hours new blocklists were distributed that got around them. This won't be possible anymore with Manifest V3, so Google just has to update their adblock implementation often enough to finally get rid of them. And the same goes for other platforms. Once the majority of users is using browsers that only allow declarative blocking, more platforms will start updating more frequently.