I saw V2 extensions will be disabled but in my lack of webdev experience I fail to point to what is prohibitive in V3 that uBlock Origin cannot migrate to.
Anyone have a better understanding and can clue us in?
Currently, uBlock Origin and other ad blockers rely on features enabled by the webRequestBlocking permission, which lets them block any request that is only useful for ads or tracking. Manifest V3 hides webRequestBlocking abilities except from extensions that are force-installed, or installed through policy for an organization.
That said, Chrome removing Manifest V2 will not kill uBlock Origin on Chrome. uBlock Origin’s Manifest V3 support page says as much:
Rest assured, uBlock will continue to function on the Manifest V3 platform!
In practice, though, that means Chrome users who don’t switch to Firefox will probably need to make do with uBlock Lite (which, for example, cannot yet circumvent YouTube’s new anti-adblocker popup). Meanwhile, Manifest V2 will join the list of reasons that uBlock Origin works best on Firefox. A comparison of uBlock Lite vs uBlock Origin
I’m curious how, if at all, this will affect Brave browser who is chromium based but natively bakes in ad block and tracker block. I assume manifest v3 is an API change, so unless Brave uses the API under the hood they should not be affected. But their performance is pretty stellar so maybe they have something more native to achieve this.
EDIT: WOW! checked the bug tracker and manifest V3 announcement goes back to 2018
Brave plans to continue supporting Manifest V2 after Google kills it. For Ungoogled Chromium, however, it’s still undecided, likely depending on whether UG contributors are willing to maintain it.
It won’t allow the extension access to the requests. This is good for securityin general, but that’s kinda important to what ad blockers do.
The replacement is that they can provide the browser with a list of rules to block. The problem is that there is a max length to that list that is something like 1/3 of the current block list.
I saw V2 extensions will be disabled but in my lack of webdev experience I fail to point to what is prohibitive in V3 that uBlock Origin cannot migrate to.
Anyone have a better understanding and can clue us in?
Currently, uBlock Origin and other ad blockers rely on features enabled by the
webRequestBlockingpermission, which lets them block any request that is only useful for ads or tracking. Manifest V3 hideswebRequestBlockingabilities except from extensions that are force-installed, or installed through policy for an organization.That said, Chrome removing Manifest V2 will not kill uBlock Origin on Chrome. uBlock Origin’s Manifest V3 support page says as much:
In practice, though, that means Chrome users who don’t switch to Firefox will probably need to make do with uBlock Lite (which, for example, cannot yet circumvent YouTube’s new anti-adblocker popup). Meanwhile, Manifest V2 will join the list of reasons that uBlock Origin works best on Firefox. A comparison of uBlock Lite vs uBlock Origin
Anyway, that’s the challenge (and gorhill’s workaround so far). You can follow gorhill’s progress at https://github.com/uBlockOrigin/uBlock-issues/issues/338
welp! thanks for laying it out.
I’m curious how, if at all, this will affect Brave browser who is chromium based but natively bakes in ad block and tracker block. I assume manifest v3 is an API change, so unless Brave uses the API under the hood they should not be affected. But their performance is pretty stellar so maybe they have something more native to achieve this.
EDIT: WOW! checked the bug tracker and manifest V3 announcement goes back to 2018
Brave plans to continue supporting Manifest V2 after Google kills it. For Ungoogled Chromium, however, it’s still undecided, likely depending on whether UG contributors are willing to maintain it.
you’re incredibly helpful! thanks for linking these threads
It won’t allow the extension access to the requests. This is good for securityin general, but that’s kinda important to what ad blockers do.
The replacement is that they can provide the browser with a list of rules to block. The problem is that there is a max length to that list that is something like 1/3 of the current block list.
What is to prevent the chrome developers from selectivity bypassing the content of the block list in the future?