4 ms·

It is hard to over-state the impact that MV3 will have on the current extension landscape! This move is a blatant attack from Google on power-users, always in

It is hard to over-state the impact that MV3 will have on the current extension landscape! This move is a blatant attack from Google on power-users, always in the name of "security" and performance.

rasz 4y ago
Google announced that in order to achieve security we must get rid of all "remote code" execution avenues. Really small print: "Remote code" being all code Remote to Google, as in code not residing on Google servers. User code sitting on Users disk in form of an extension installed Locally by the User into his "User Agent" is "Remote code" to Google.
- svnpenn 4y ago
  > "Remote code" being all code Remote to Google, as in code not residing on Google servers. User code sitting on Users disk in form of an extension installed Locally by the User into his "User Agent" is "Remote code" to Google. Replace Google with Mozilla, and you still have an accurate statement: https://github.com/mozilla-mobile/fenix/issues/20647 https://github.com/mozilla-mobile/fenix/issues/20647
hbn 4y ago
I don't even think you can say adblockers are a "power user" feature. The web is so bloated and bad that it's virtually unusable without it. I hope this gets found as the anti-competitive move that it is. They're taking advantage of their near-monopoly that they have in the browser space to force people to view more of their own ads. It's disgusting.
- Raed667 4y ago
  Adblocking is the tip of the iceburg. Proxying, dev-tools that manipulate CORS, rule-based cosmetic filters etc... will also be impacted. The other huge change that most people don't know about, is the move from a persistent background.js script to a sevice-worker will just make a number of use-cases impossible or very hacky
  - aeharding 4y ago
    > the move from a persistent background.js script to a sevice-worker will just make a number of use-cases impossible or very hacky Yep. Chrome is even crippling some of their own APIs, like chrome.tabCapture (not available in service workers, and in mv3 will be "foreground only") AKA, if you want to use chrome.tabCapture in mv3, you have to run it in a tab. And because that tab can be closed at any time, you need to serialize megabytes of data to the chrome.storage api every few seconds.
    - msallese31 4y ago
      Does running it in a content script even work? I've only been able to run tabCapture in the popup. I don't see how any screen recording extensions can work in MV3
Vinnl 4y ago
Yet lots of people seem to manage, e.g. by stating that adblockers will cease to function entirely.
- Raed667 4y ago
  I have tried both uBlock Minus[0] and AdguardMV3[1] and can confidently say that they're barely a shadow of their manifest-v2 versions. [0] https://github.com/gorhill/uBlock/tree/master/platform/mv3 https://github.com/gorhill/uBlock/tree/master/platform/mv3 [1] https://github.com/AdguardTeam/AdGuardMV3 https://github.com/AdguardTeam/AdGuardMV3
  - Vinnl 4y ago
    I'm not familiar with Adguard, but uBO Minus is meant to be a shadow of regular uBO, because it tries not to request page permissions for every website by default. Presumably, an actual MV3 version will do that and use that to at least fall back to visual blocking if request blocking is not possible.
    - Raed667 4y ago
      You can easily tweak the manifest.json to grant the extension permissions on all urls. Give it a shot and see that it still falls behind and doesn't block much of the annoyances.
      - Vinnl 4y ago
        Yeah but just granting it doesn't make it actually make use of it, no? Or are you referring to the recent update where it allows you to give permission on a per-website basis where it will do more blocking? If so, then I believe you and then it's worse than I thought.
        Raed667 4y ago
        You don't have to believe me, you can try my fork pre-built here https://github.com/raed667/uBlock-minus-mv3-cs-poc/releases/tag/host_permissions https://github.com/raed667/uBlock-minus-mv3-cs-poc/releases/...

It is hard to over-state the impact that MV3 will have on the current extension landscape! This move is a blatant attack from Google on power-users, always in the name of "security" and performance.

rasz 4y ago

Google announced that in order to achieve security we must get rid of all "remote code" execution avenues. Really small print: "Remote code" being all code Remote to Google, as in code not residing on Google servers. User code sitting on Users disk in form of an extension installed Locally by the User into his "User Agent" is "Remote code" to Google.

svnpenn 4y ago
> "Remote code" being all code Remote to Google, as in code not residing on Google servers. User code sitting on Users disk in form of an extension installed Locally by the User into his "User Agent" is "Remote code" to Google. Replace Google with Mozilla, and you still have an accurate statement: https://github.com/mozilla-mobile/fenix/issues/20647 https://github.com/mozilla-mobile/fenix/issues/20647

hbn 4y ago

I don't even think you can say adblockers are a "power user" feature. The web is so bloated and bad that it's virtually unusable without it. I hope this gets found as the anti-competitive move that it is. They're taking advantage of their near-monopoly that they have in the browser space to force people to view more of their own ads. It's disgusting.

Raed667 4y ago
Adblocking is the tip of the iceburg. Proxying, dev-tools that manipulate CORS, rule-based cosmetic filters etc... will also be impacted. The other huge change that most people don't know about, is the move from a persistent background.js script to a sevice-worker will just make a number of use-cases impossible or very hacky
- aeharding 4y ago
  > the move from a persistent background.js script to a sevice-worker will just make a number of use-cases impossible or very hacky Yep. Chrome is even crippling some of their own APIs, like chrome.tabCapture (not available in service workers, and in mv3 will be "foreground only") AKA, if you want to use chrome.tabCapture in mv3, you have to run it in a tab. And because that tab can be closed at any time, you need to serialize megabytes of data to the chrome.storage api every few seconds.
  - msallese31 4y ago
    Does running it in a content script even work? I've only been able to run tabCapture in the popup. I don't see how any screen recording extensions can work in MV3

Vinnl 4y ago

Yet lots of people seem to manage, e.g. by stating that adblockers will cease to function entirely.

Raed667 4y ago
I have tried both uBlock Minus[0] and AdguardMV3[1] and can confidently say that they're barely a shadow of their manifest-v2 versions. [0] https://github.com/gorhill/uBlock/tree/master/platform/mv3 https://github.com/gorhill/uBlock/tree/master/platform/mv3 [1] https://github.com/AdguardTeam/AdGuardMV3 https://github.com/AdguardTeam/AdGuardMV3
- Vinnl 4y ago
  I'm not familiar with Adguard, but uBO Minus is meant to be a shadow of regular uBO, because it tries not to request page permissions for every website by default. Presumably, an actual MV3 version will do that and use that to at least fall back to visual blocking if request blocking is not possible.
  - Raed667 4y ago
    You can easily tweak the manifest.json to grant the extension permissions on all urls. Give it a shot and see that it still falls behind and doesn't block much of the annoyances.
    - Vinnl 4y ago
      Yeah but just granting it doesn't make it actually make use of it, no? Or are you referring to the recent update where it allows you to give permission on a per-website basis where it will do more blocking? If so, then I believe you and then it's worse than I thought.
      - Raed667 4y ago
        You don't have to believe me, you can try my fork pre-built here https://github.com/raed667/uBlock-minus-mv3-cs-poc/releases/tag/host_permissions https://github.com/raed667/uBlock-minus-mv3-cs-poc/releases/...