6 ms·

That doesn't seem to show how to install an XPI file locally? Unless I'm missing something that's some web interface from AMO

by ahbyb 7y ago

minty_phoenix 7y ago
The original article only discusses a specific, non-standard (to me, at least – probably made more sense for IT departments) method that Mozilla is calling ‘sideloading’ will be disabled. Per the article, ‘sideloading’ is defined as putting an extension file in a special folder that results in all instances of Firefox on the machine automatically loading that extension. In the page yorwba linked, it shows how to generate a signed XPI file that can be distributed and installed locally from that file in a more conventional manner (e.g. drag & drop the file onto Firefox’s Add-ons page).
- derefr 7y ago
  > probably made more sense for IT departments Yes, the older method of extension side-loading, supported at some point by Edge, Chrome, and Firefox, was for IT departments who created OS deployment images with software (incl. extensions) burned into them. Usually this was combined with Group Policy / Device Profile settings that made the extensions impossible to deactivate or remove ("force enabled") and potentially blocked any extensions other than those preinstalled. I believe that all the browser makers have, at this point, reached a consensus that deploying extensions directly as on-disk files this way makes it 1. too easy for malware to just set itself up as seemingly "deployed by Group Policy"; and 2. makes it too hard for these extensions to be updated as often as they might need to be, or disabled if the browser-maker declares incompatibility with an API in them, etc. What all the browser-makers seem to favor nowadays, for IT departments who want to do OS-image deployment, is an approach where the burned-in Group Policy will just list out a set of extension IDs that are to be force-installed and force-enabled; and then the browser itself will do the work of retrieving and installing them (but will still treat them like any other extension as it goes through the install process, vetting it for compatibility, upgrading it through its registered upgrade channel, etc.) This means that every extension in these browsers now has to live in the browser's extension store—even if it's a private, just-for-your-own-company extension. (Which, honestly, there's not much to be said against; the "enterprise deployment" parts of app-stores don't usually force developers to go through pre-vetting before new versions are published or anything. It's just cloud hosting—with the proviso that, due to having download logs, the app-store can see if your "enterprise extension" has an install profile that looks more like that of a virus rather than an enterprise, and then blacklist it.) Here's Google's documentation on the Group Policy settings that modern Chrome looks for, for comparison: https://support.google.com/chrome/a/answer/7532015?hl=en https://support.google.com/chrome/a/answer/7532015?hl=en. Probably Firefox wants to move toward a similar model. And more power to them, honestly; right now, Firefox's extension ecosystem is far too easy a target for malware authors.
nstart 7y ago
From what I know (and I've got quite a few self developed addons running), installing unsigned XPI files has not been allowed for a while. I've been uploading them to my profile in the add-ons developer portal and getting back the signed XPI file. I could be misreading this though so apologies if I jumped the gun here.
- ahbyb 7y ago
  If you have to upload your addons to the internet before you can install them (even if it is to have them signed) that's hardly "local".
  - callahad 7y ago
    Signing is only required on official release and beta builds -- users on developer edition, nightly, and unbranded builds can opt-out of the signing requirement by flipping a setting in about:config.
    - deleted 7y ago
      [deleted]
    - whitexn--g28h 7y ago
      Unsigned extensions are also not for end-users.
      - apostacy 7y ago
        > Unsigned extensions are also not for end-users. Says who??? Part of the problem is the very delineation between developer and end user. How about Firefox just be a powerful open platform that anyone can develop for easily with as few roadblocks as possible? We should all be one step away from being developers. I am so glad I was on the old Firefox 12 years ago. I'm glad that I was able to quickly whip up extensions and share them with my friends. Wanting to automate bypassing my school's wifi captive portal, or wanting to change how the bookmark menu was displayed encouraged me to experiment. The fact that Mozilla now sees only an audience of consumers that need to be protected from themselves and marketed to is the problem. Mozilla is afraid of their precious precious brand being sullied.

That doesn't seem to show how to install an XPI file locally? Unless I'm missing something that's some web interface from AMO

by ahbyb 7y ago

That doesn't seem to show how to install an XPI file locally? Unless I'm missing something that's some web interface from AMO

minty_phoenix 7y ago

The original article only discusses a specific, non-standard (to me, at least – probably made more sense for IT departments) method that Mozilla is calling ‘sideloading’ will be disabled. Per the article, ‘sideloading’ is defined as putting an extension file in a special folder that results in all instances of Firefox on the machine automatically loading that extension. In the page yorwba linked, it shows how to generate a signed XPI file that can be distributed and installed locally from that file in a more conventional manner (e.g. drag & drop the file onto Firefox’s Add-ons page).

derefr 7y ago
> probably made more sense for IT departments Yes, the older method of extension side-loading, supported at some point by Edge, Chrome, and Firefox, was for IT departments who created OS deployment images with software (incl. extensions) burned into them. Usually this was combined with Group Policy / Device Profile settings that made the extensions impossible to deactivate or remove ("force enabled") and potentially blocked any extensions other than those preinstalled. I believe that all the browser makers have, at this point, reached a consensus that deploying extensions directly as on-disk files this way makes it 1. too easy for malware to just set itself up as seemingly "deployed by Group Policy"; and 2. makes it too hard for these extensions to be updated as often as they might need to be, or disabled if the browser-maker declares incompatibility with an API in them, etc. What all the browser-makers seem to favor nowadays, for IT departments who want to do OS-image deployment, is an approach where the burned-in Group Policy will just list out a set of extension IDs that are to be force-installed and force-enabled; and then the browser itself will do the work of retrieving and installing them (but will still treat them like any other extension as it goes through the install process, vetting it for compatibility, upgrading it through its registered upgrade channel, etc.) This means that every extension in these browsers now has to live in the browser's extension store—even if it's a private, just-for-your-own-company extension. (Which, honestly, there's not much to be said against; the "enterprise deployment" parts of app-stores don't usually force developers to go through pre-vetting before new versions are published or anything. It's just cloud hosting—with the proviso that, due to having download logs, the app-store can see if your "enterprise extension" has an install profile that looks more like that of a virus rather than an enterprise, and then blacklist it.) Here's Google's documentation on the Group Policy settings that modern Chrome looks for, for comparison: https://support.google.com/chrome/a/answer/7532015?hl=en https://support.google.com/chrome/a/answer/7532015?hl=en. Probably Firefox wants to move toward a similar model. And more power to them, honestly; right now, Firefox's extension ecosystem is far too easy a target for malware authors.

nstart 7y ago

From what I know (and I've got quite a few self developed addons running), installing unsigned XPI files has not been allowed for a while. I've been uploading them to my profile in the add-ons developer portal and getting back the signed XPI file. I could be misreading this though so apologies if I jumped the gun here.

ahbyb 7y ago
If you have to upload your addons to the internet before you can install them (even if it is to have them signed) that's hardly "local".
- callahad 7y ago
  Signing is only required on official release and beta builds -- users on developer edition, nightly, and unbranded builds can opt-out of the signing requirement by flipping a setting in about:config.
  - deleted 7y ago
    [deleted]
  - whitexn--g28h 7y ago
    Unsigned extensions are also not for end-users.
    - apostacy 7y ago
      > Unsigned extensions are also not for end-users. Says who??? Part of the problem is the very delineation between developer and end user. How about Firefox just be a powerful open platform that anyone can develop for easily with as few roadblocks as possible? We should all be one step away from being developers. I am so glad I was on the old Firefox 12 years ago. I'm glad that I was able to quickly whip up extensions and share them with my friends. Wanting to automate bypassing my school's wifi captive portal, or wanting to change how the bookmark menu was displayed encouraged me to experiment. The fact that Mozilla now sees only an audience of consumers that need to be protected from themselves and marketed to is the problem. Mozilla is afraid of their precious precious brand being sullied.