4 ms·

This is the first time I've really looked into Manifest V3, and I'm confused as to how the "no remote JS" restriction is enforced. What prevents a developer fr

This is the first time I've really looked into Manifest V3, and I'm confused as to how the "no remote JS" restriction is enforced. What prevents a developer from using non-remote JS (code built into the extension) to tell the current web page to fetch remote JS from a server, and execute that? Obviously, web pages must be able to fetch remote JS, or the whole internet would break. Google could delist such an extension from the Chrome Web Store. But Chrome (unlike Firefox, grr!) allows extension sideloading, so if I was UBlock Origin I would just say screw the Web Store, download from our website. And then, once UBlock Origin can inject an unlimited amount of turing-complete Javascript onto the page, the sky is basically the limit... right?

ameshkov 3y ago
If the server is yours it will probably be rejected. Definitely will be rejected by Mozilla. Userscripts is a notable exception of this rule as in this case the user instructs the extension what JS to execute.
- Wowfunhappy 3y ago
  Yes, but Chrome allows users to sideload extensions.
  - ameshkov 3y ago
    Firefox kinda also does. In both cases side loading is rather painful experience, thanks to all the malware that is exploiting the extensions feature.
    - Wowfunhappy 3y ago
      Firefox extensions don't need to be listed in the web store, but they must be signed by Mozilla, no exceptions. I have used both browsers, and I find sideloading in Chrome to be completely painless. I use many sideloaded extensions in Chrome (mostly because I wanted to make small edits to existing extensions). I guess I'm trying to figure out whether all this fuss is really a limitation of Manifest v3, or merely Chrome Web Store policy. If the latter, I don't see a problem as long as sideloading is possible, and I really hope UBlock Origin will just go that route. Sideloading is the real freedom which everyone should rally around and protect. (I am extremely unhappy with Mozilla's approach to this, if you can't tell.)
      - ameshkov 3y ago
        The most problematic part of MV3 (removing part of the webRequest API functionality) is a part of the platform. This remote JS stuff is a CWS policy.
        Wowfunhappy 3y ago
        So what can the webRequest API do that couldn't just be accomplished via Javascript injection? From my perspective—admittedly not really understanding how UBlock Origin works—Javascript is basically all-powerful on a web page. Once you have that, I'm surprised that anything else could be a meaningful restriction. (I appreciate you answering my questions!)
        ameshkov 3y ago
        JS is important, but it’s only a part of what’s required. webRequest allows the extension to manipulate web requests: blocking or redirecting them. MV3 tries to replace the old webRequest with a declarative alternative and it’s almost impossible to provide a declarative rule for every possible use case.
        lxgr 3y ago
        Javascript is very powerful, but simple injected Javascript can't e.g. undo requests (from other scripts or just normal resources like third-party images) that have already happened. An injected script is not guaranteed to run before the site's own scripts, I believe. Other than that, you can probably really do everything you could do with the webRequest API, but the complexity of doing it essentially reduces to the halting problem: You'd have to statically analyze all Javascript loaded by the page and figure out if it's going to do any requests you don't want to happen and then rewrite these parts. Maybe there's clever things you could do by shimming all web APIs that can issue HTTP or other requests, but that also doesn't sound fun. On the other hand, with an API that just gets to veto every outgoing request, you can trivially achieve the same goal. Another area where in-page Javascript is limited compared to an extension is the same origin policy. A very fancy ad-blocking extension could e.g. run an image classification AI on third-party image resources and hide the ones that look like visually distracting, flashing etc. ads by default – in-page Javascript can't.
  - lxgr 3y ago
    Getting non-technical users used to regularly sideloading extensions sounds like a recipe for disaster in terms of security. I'm also not sure if sideloaded extensions can receive automatic updates, but the much bigger problem is getting people used to sideloading unsigned extensions with full web site access: Tech support scammers will have a field day with that.
    - Wowfunhappy 3y ago
      It wouldn't be good for security. But I fundamentally believe that user freedom—the ability to do what big tech would rather they did not, such as adblocking—fundamentally depends on sideloading. You simply can't have one without the other. You're trusting the vendor to decide which software is safe, but that vendor will inevitably also consider which software makes them money. On platforms where sideloading is either impossible (iOS) or usual (Android), adblockers are completely inaffective. The gatekeepers simply don't allow them to exist. This is true even though the maker of iOS ostensibly (!) isn't ad supported. > I'm also not sure if sideloaded extensions can receive automatic updates They can't (at least without some external software), which is why the ability to load remote Javascript would be important. For less frequent updates, they could prompt the user.
      - no_wizard 3y ago
        There’s a legal avenue for this kind of thing too: pass laws that enforce clear and transparent rules around what the gatekeeper can do and give legal recourse to participants to hold said gatekeeper accountable if they break them.
        Wowfunhappy 3y ago
        But it's still like putting the coal companies in charge of the EPA. You can add laws and mandates to try to tie their hands, but they're going to push the boundaries as much as they possibly can. You could have app approvals go through some truly public, government-run agency... except frankly I'd object to that too on free-speech grounds.
      - 3y ago
  - vGPU 3y ago
    > Unsigned extensions can be installed in the Developer Edition, Nightly, and ESR versions of Firefox, after toggling the xpinstall. signatures. required preference in about:config So I guess not in regular?
    - Wowfunhappy 3y ago
      Exactly, not in regular, in those builds the xpinstall flag is ignored. A lot of people recommend switching to Developer Edition to use unsigned extensions, but that's aligned to the Beta update channel. There's no way to get stable releases + unsigned extensions. Whatever the security argument, I find this completely antithetical to user freedom, especially given that it's allowed in Chrome! I just can't believe that Mozilla is the one restricting their own users. (It's also news to me that unsigned extensions can be enabled in ESR, I thought it was just Nightly and Developer. That's nice I guess.)
      - vGPU 3y ago
        Agreed, it’s definitely not in line with their stated philosophy. Sadly, Mozilla has been drifting away from it more and more lately.
deleted 3y ago
[deleted]
squeaky-clean 3y ago
I used to run a homebrew'd extension to change my new tab page. Chrome makes it so annoying to use a sideloaded extension. Every time you start the browser, and every couple of hours when you open a new tab it will have a big popup warning you that an unsigned extension is running, and give you a big button to remove the extension that fires when you hit space or enter, and a tiny little subtext button to continue using the extension. After the 3rd time accidentally uninstalling the extension because I was typing in a search too quickly and not paying attention, I gave up on using it.
- aardshark 3y ago
  You must be able to turn this off, because I've been running many homebrewed extensions for years and never encountered these popups.
- Wowfunhappy 3y ago
  Huh, I've never seen this. Are you loading extensions via "load unpacked" (which is what I use) or some other method I'm unaware of?

ameshkov 3y ago

If the server is yours it will probably be rejected. Definitely will be rejected by Mozilla. Userscripts is a notable exception of this rule as in this case the user instructs the extension what JS to execute.

Wowfunhappy 3y ago
Yes, but Chrome allows users to sideload extensions.
- ameshkov 3y ago
  Firefox kinda also does. In both cases side loading is rather painful experience, thanks to all the malware that is exploiting the extensions feature.
  - Wowfunhappy 3y ago
    Firefox extensions don't need to be listed in the web store, but they must be signed by Mozilla, no exceptions. I have used both browsers, and I find sideloading in Chrome to be completely painless. I use many sideloaded extensions in Chrome (mostly because I wanted to make small edits to existing extensions). I guess I'm trying to figure out whether all this fuss is really a limitation of Manifest v3, or merely Chrome Web Store policy. If the latter, I don't see a problem as long as sideloading is possible, and I really hope UBlock Origin will just go that route. Sideloading is the real freedom which everyone should rally around and protect. (I am extremely unhappy with Mozilla's approach to this, if you can't tell.)
    - ameshkov 3y ago
      The most problematic part of MV3 (removing part of the webRequest API functionality) is a part of the platform. This remote JS stuff is a CWS policy.
      - Wowfunhappy 3y ago
        So what can the webRequest API do that couldn't just be accomplished via Javascript injection? From my perspective—admittedly not really understanding how UBlock Origin works—Javascript is basically all-powerful on a web page. Once you have that, I'm surprised that anything else could be a meaningful restriction. (I appreciate you answering my questions!)
        ameshkov 3y ago
        JS is important, but it’s only a part of what’s required. webRequest allows the extension to manipulate web requests: blocking or redirecting them. MV3 tries to replace the old webRequest with a declarative alternative and it’s almost impossible to provide a declarative rule for every possible use case.
        lxgr 3y ago
        Javascript is very powerful, but simple injected Javascript can't e.g. undo requests (from other scripts or just normal resources like third-party images) that have already happened. An injected script is not guaranteed to run before the site's own scripts, I believe. Other than that, you can probably really do everything you could do with the webRequest API, but the complexity of doing it essentially reduces to the halting problem: You'd have to statically analyze all Javascript loaded by the page and figure out if it's going to do any requests you don't want to happen and then rewrite these parts. Maybe there's clever things you could do by shimming all web APIs that can issue HTTP or other requests, but that also doesn't sound fun. On the other hand, with an API that just gets to veto every outgoing request, you can trivially achieve the same goal. Another area where in-page Javascript is limited compared to an extension is the same origin policy. A very fancy ad-blocking extension could e.g. run an image classification AI on third-party image resources and hide the ones that look like visually distracting, flashing etc. ads by default – in-page Javascript can't.
- lxgr 3y ago
  Getting non-technical users used to regularly sideloading extensions sounds like a recipe for disaster in terms of security. I'm also not sure if sideloaded extensions can receive automatic updates, but the much bigger problem is getting people used to sideloading unsigned extensions with full web site access: Tech support scammers will have a field day with that.
  - Wowfunhappy 3y ago
    It wouldn't be good for security. But I fundamentally believe that user freedom—the ability to do what big tech would rather they did not, such as adblocking—fundamentally depends on sideloading. You simply can't have one without the other. You're trusting the vendor to decide which software is safe, but that vendor will inevitably also consider which software makes them money. On platforms where sideloading is either impossible (iOS) or usual (Android), adblockers are completely inaffective. The gatekeepers simply don't allow them to exist. This is true even though the maker of iOS ostensibly (!) isn't ad supported. > I'm also not sure if sideloaded extensions can receive automatic updates They can't (at least without some external software), which is why the ability to load remote Javascript would be important. For less frequent updates, they could prompt the user.
    - no_wizard 3y ago
      There’s a legal avenue for this kind of thing too: pass laws that enforce clear and transparent rules around what the gatekeeper can do and give legal recourse to participants to hold said gatekeeper accountable if they break them.
      - Wowfunhappy 3y ago
        But it's still like putting the coal companies in charge of the EPA. You can add laws and mandates to try to tie their hands, but they're going to push the boundaries as much as they possibly can. You could have app approvals go through some truly public, government-run agency... except frankly I'd object to that too on free-speech grounds.
    - 3y ago
- vGPU 3y ago
  > Unsigned extensions can be installed in the Developer Edition, Nightly, and ESR versions of Firefox, after toggling the xpinstall. signatures. required preference in about:config So I guess not in regular?
  - Wowfunhappy 3y ago
    Exactly, not in regular, in those builds the xpinstall flag is ignored. A lot of people recommend switching to Developer Edition to use unsigned extensions, but that's aligned to the Beta update channel. There's no way to get stable releases + unsigned extensions. Whatever the security argument, I find this completely antithetical to user freedom, especially given that it's allowed in Chrome! I just can't believe that Mozilla is the one restricting their own users. (It's also news to me that unsigned extensions can be enabled in ESR, I thought it was just Nightly and Developer. That's nice I guess.)
    - vGPU 3y ago
      Agreed, it’s definitely not in line with their stated philosophy. Sadly, Mozilla has been drifting away from it more and more lately.

deleted 3y ago

[deleted]

squeaky-clean 3y ago

I used to run a homebrew'd extension to change my new tab page. Chrome makes it so annoying to use a sideloaded extension. Every time you start the browser, and every couple of hours when you open a new tab it will have a big popup warning you that an unsigned extension is running, and give you a big button to remove the extension that fires when you hit space or enter, and a tiny little subtext button to continue using the extension. After the 3rd time accidentally uninstalling the extension because I was typing in a search too quickly and not paying attention, I gave up on using it.

aardshark 3y ago
You must be able to turn this off, because I've been running many homebrewed extensions for years and never encountered these popups.
Wowfunhappy 3y ago
Huh, I've never seen this. Are you loading extensions via "load unpacked" (which is what I use) or some other method I'm unaware of?