MV3 splits permissions into host permissions and classical permissions (tabs, storage, etc). Putting <all_urls> in your host permission list means that whatever the extension does, it can do it on all possible urls you may visit in the browser. In this sense, it's no different than in MV2.
What's different is the classical permissions. Previously you could use the webRequest permission to execute custom JS functions in response to network activity. In MV3 you must now write a declarative rule instead using the declarativeNetRequest permission. By moving from an imperitive model to a declarative one, Google now has exacting control over what ad blockers can and can't do.
Gorhill's argument is that the stated reasons for MV3 do not align with the implementation. The example he gives is that Google claims the new API is more private. However you still need <all_urls> so the extension is as un-private as its MV2 equivalent. The only difference is that now Google controls what blocking you're allowed to declare and how much of it you're allowed to do.
There's a similar community discovery where MV3 implementation is provably counter to Google's claims of performance enhancement - MV3 extensions need to rehydrate state every 5 minutes as Chrome shuts down their service worker and for highly active extensions such as ad blockers this is actually less performant than the MV2 implementation with a long-lived background.
Not completely full of shit. Declarative rules are a good idea in the general case. Random browser extensions really should not have unrestricted access to the network requests. This is how we get malware.
It's just that uBlock Origin is so important and trusted that these limitations should not apply to it. I'd even say ad blockers should be a built in browser feature but the conflicts of interest prevent that.
Now that ad blockers have to be built out of declarative syntax that Google controls, the browser maintainers basically _are_ responsible for implementing the ad blockers. And would you look at that they're pushing back on community contributions and dragging their feet because yes, there is a conflict of interest.
They left alone other imperative-but-dangerous aspects of extensions, such as the ability for any extension to watch what you type into password or credit card fields on any website. Actually that sort of extension is even easier to write in MV3 and Google will still need JS-reviewing wizards to give a guarantee an extension isn't snooping your passwords.
I don't think there's a consistent position from Google if the claim is they want to improve security via declarative syntax. I think Google is full of shit.
I agree with you. I just think this declarative API could have been a good move were it not for the conflict of interest. Makes me wish gorhill made his owh browser instead of browser extensions.
> Not completely full of shit. Declarative rules are a good idea in the general case.
The heavily depends and I would disagree here. Yes, JS execution is unpopular, but it enables you to make your app behave like you want to. Otherwise it behaves like Google wants to. Google is no scammer at least, but the end result is suboptimal.
Only if you've already accepted that a loss in functionality is acceptable.
If you could implement a declarative language as powerful as an imperative one you could solve the halting problem.
So the switch from imperative to declarative is not free to make and Google has thrown the baby out with the bathwater. They just so happen to lose money every second that baby is alive. On the one hand, the decision to implement this specific declarative language is a malicious exertion of market force. On the other hand it's a stunning display of implementation incompetence. The language can't even reimplement the most popular existing extensions.
What's different is the classical permissions. Previously you could use the webRequest permission to execute custom JS functions in response to network activity. In MV3 you must now write a declarative rule instead using the declarativeNetRequest permission. By moving from an imperitive model to a declarative one, Google now has exacting control over what ad blockers can and can't do.
Gorhill's argument is that the stated reasons for MV3 do not align with the implementation. The example he gives is that Google claims the new API is more private. However you still need <all_urls> so the extension is as un-private as its MV2 equivalent. The only difference is that now Google controls what blocking you're allowed to declare and how much of it you're allowed to do.
There's a similar community discovery where MV3 implementation is provably counter to Google's claims of performance enhancement - MV3 extensions need to rehydrate state every 5 minutes as Chrome shuts down their service worker and for highly active extensions such as ad blockers this is actually less performant than the MV2 implementation with a long-lived background.
Basically, Google is full of shit.