5 ms·

> this commit removes the "scriplet injection" Considering this is stated in ManifestV3's announcement and that no APIs have been made for it: > Beginning in

> this commit removes the "scriplet injection" Considering this is stated in ManifestV3's announcement and that no APIs have been made for it: > Beginning in Manifest V3, we will disallow extensions from using remotely-hosted code. This will require that all code executed by the extension be present in the extension’s package uploaded to the webstore. Server communication (potentially changing extension behavior) will still be allowed. This will help us better review the extensions uploaded, and keep our users safe. We will leverage a minimum required CSP to help enforce this (though it will not be 100% unpreventable, and we will require policy and manual review enforcement as well). Scriptlet injection is as good as dead. > and cosmetic filtering features, Cosmetic filtering can only happen by making a service worker, that will turn on five seconds after the page has loaded. > the "read/modify data" permission isn't getting removed by MV3? No, but Google will heavily restrict any extension using this permission, and make the requirements to be published on their extension store so draconian that an ad blocking extension (which directly threatens their business model) has no chance of ever being accepted. So, no, Google, as usual when they implement a new API, does half assed shit, breaks compatibility, forces everyone to follow on their bad decisions before deprecating it later. Going all in on MV3 is just bringing yourself to the slaughter, and MV3 should be laughed off by any serious extension developer.

caladin 4y ago
One interesting consequence of this is that Google's own javascript api client will no longer work with MV3 and there are apparently no plans to ever make it work. See https://github.com/google/google-api-javascript-client/issues/713 https://github.com/google/google-api-javascript-client/issue... Chromium bug marked WONTFIX: https://bugs.chromium.org/p/chromium/issues/detail?id=1164452 https://bugs.chromium.org/p/chromium/issues/detail?id=116445... Updated readme: https://github.com/google/google-api-javascript-client/blob/master/docs/start.md#supported-environments https://github.com/google/google-api-javascript-client/blob/... So effectively this means extensions on MV3 can't easily access Google apis, which is quite unfortunate since Chrome extensions in particular made Google authentication super straightforward (piggybacking off of chrome's built-in google authentication). If someone knows a better way I'd love to hear it. I believe the reason that the current incarnation of the javascript library won't work is because it modifies the dom to add script tags to fetch and run the api library (or components of it), which is specifically what MV3 will disallow AFAIK.
- somehnacct3757 4y ago
  MV3 nukes pretty much every third party js in existence. If the lack of a DOM doesn't do it, the extremely spartan service worker environment will take it out. Did they use XHR? SW only supports fetch. Did they use the window global? Don't have one of those either. It's the stone ages right now. If you want to integrate with a third party in MV3 you are building a fetch wrapper around their raw HTTP API. Google thinks this is production ready
nightpool 4y ago
> Considering this is stated in ManifestV3's announcement and that no APIs have been made for it I'll admit—when I first made this comment, I assumed (based on the initial manifest v3 draft) that this change only affected privileged context execution, and did not affect execution in the "main world", outside of privileged extension contexts. That said, APIs HAVE been made for it, and it would still be possible to do this using the dynamic addContentScript feature, even though I'd imagine it's a very low priority change to implement for the uBlock team (how many rules even use scriptlets?). But this is only a very small part of the features that Gorhill removed from the extension > Cosmetic filtering can only happen by making a service worker, that will turn on five seconds after the page has loaded. What? Content scripts still exist. Scriptlets may be harder to implement, but there's absolutely no reason cosmetic filtering should be. > No, but Google will heavily restrict any extension using this permission, and make the requirements to be published on their extension store so draconian that an ad blocking extension (which directly threatens their business model) has no chance of ever being accepted. Source? Have they said that they're going to do this to uBlock origin? They've said time and time again that making sure ad blocking extensions continue to work is one of their highest priority goals with MV3. Also, the DNR changes absolutely do not make a meaningful impact on Google's business model—Google's ads are very, very easy to block, and you could do it with a one-line chrome extension. The vast majority of complexity in ad blockers is required for other ads that live outside of Google's ecosystem. If you really believed that Google was making their MV3 changes based on their business goals for their ads team (a pretty ludicrous idea when you think about how big Google is and how far separated the ads department and extensions teams are), then the inescapable conclusion is that Google should be supporting ad blockers themselves, to hurt the smaller companies that threaten their monopoly by trying to work around ad blockers.
- ohgodplsno 4y ago
  "Source" he asks as the perpetually incompetent and straight up evil Chrome team deletes powerful APIs with no good replacement that just so happen to be the exact ones that blocks Google's extensive data collection and tracking. Feel free to be in denial about why those crippled APIs have come to be.

caladin 4y ago

One interesting consequence of this is that Google's own javascript api client will no longer work with MV3 and there are apparently no plans to ever make it work. See https://github.com/google/google-api-javascript-client/issues/713 https://github.com/google/google-api-javascript-client/issue... Chromium bug marked WONTFIX: https://bugs.chromium.org/p/chromium/issues/detail?id=1164452 https://bugs.chromium.org/p/chromium/issues/detail?id=116445... Updated readme: https://github.com/google/google-api-javascript-client/blob/master/docs/start.md#supported-environments https://github.com/google/google-api-javascript-client/blob/... So effectively this means extensions on MV3 can't easily access Google apis, which is quite unfortunate since Chrome extensions in particular made Google authentication super straightforward (piggybacking off of chrome's built-in google authentication). If someone knows a better way I'd love to hear it. I believe the reason that the current incarnation of the javascript library won't work is because it modifies the dom to add script tags to fetch and run the api library (or components of it), which is specifically what MV3 will disallow AFAIK.

somehnacct3757 4y ago
MV3 nukes pretty much every third party js in existence. If the lack of a DOM doesn't do it, the extremely spartan service worker environment will take it out. Did they use XHR? SW only supports fetch. Did they use the window global? Don't have one of those either. It's the stone ages right now. If you want to integrate with a third party in MV3 you are building a fetch wrapper around their raw HTTP API. Google thinks this is production ready

nightpool 4y ago

> Considering this is stated in ManifestV3's announcement and that no APIs have been made for it I'll admit—when I first made this comment, I assumed (based on the initial manifest v3 draft) that this change only affected privileged context execution, and did not affect execution in the "main world", outside of privileged extension contexts. That said, APIs HAVE been made for it, and it would still be possible to do this using the dynamic addContentScript feature, even though I'd imagine it's a very low priority change to implement for the uBlock team (how many rules even use scriptlets?). But this is only a very small part of the features that Gorhill removed from the extension > Cosmetic filtering can only happen by making a service worker, that will turn on five seconds after the page has loaded. What? Content scripts still exist. Scriptlets may be harder to implement, but there's absolutely no reason cosmetic filtering should be. > No, but Google will heavily restrict any extension using this permission, and make the requirements to be published on their extension store so draconian that an ad blocking extension (which directly threatens their business model) has no chance of ever being accepted. Source? Have they said that they're going to do this to uBlock origin? They've said time and time again that making sure ad blocking extensions continue to work is one of their highest priority goals with MV3. Also, the DNR changes absolutely do not make a meaningful impact on Google's business model—Google's ads are very, very easy to block, and you could do it with a one-line chrome extension. The vast majority of complexity in ad blockers is required for other ads that live outside of Google's ecosystem. If you really believed that Google was making their MV3 changes based on their business goals for their ads team (a pretty ludicrous idea when you think about how big Google is and how far separated the ads department and extensions teams are), then the inescapable conclusion is that Google should be supporting ad blockers themselves, to hurt the smaller companies that threaten their monopoly by trying to work around ad blockers.

ohgodplsno 4y ago
"Source" he asks as the perpetually incompetent and straight up evil Chrome team deletes powerful APIs with no good replacement that just so happen to be the exact ones that blocks Google's extensive data collection and tracking. Feel free to be in denial about why those crippled APIs have come to be.