Upcoming changes to extension sideloading

Caitlin Neiman

71 responses

Sideloading is a method of installing an extension in Firefox by adding an extension file to a special location using an executable application installer. This installs the extension in all Firefox instances on a computer.

Sideloaded extensions frequently cause issues for users since they did not explicitly choose to install them and are unable to remove them from the Add-ons Manager. This mechanism has also been employed in the past to install malware into Firefox. To give users more control over their extensions, support for sideloaded extensions will be discontinued. 

November 1 update: we’ve heard some feedback expressing confusion about how this change will give more control to Firefox users. Ever since we implemented abuse reporting in Firefox 68, the top kind of report we receive by far has been extension installs that weren’t expected and couldn’t be removed, and the extensions being reported are known to be distributed through sideloading. With this change, we are enforcing more transparency in the installation process, by letting users choose whether they want to install an application companion extension or not, and letting them remove it when they want to. Developers will still be free to self-distribute extensions on the web, and users will still be able to install self-distributed extensions. Enterprise administrators will continue to be able to deploy extensions to their users via policies. Other forms of automatic extension deployment like the ones used for some Linux distributions and applications like Selenium may be impacted by these changes. We’re still investigating some technical details around these cases and will try to strike the right balance between user choice and minimal disruption.

During the release cycle for Firefox version 73, which goes into pre-release channels on December 3, 2019 and into release on February 11, 2020, Firefox will continue to read sideloaded files, but they will be copied over to the user’s individual profile and installed as regular add-ons. Sideloading will stop being supported in Firefox version 74, which will be released on March 10, 2020. The transitional stage in Firefox 73 will ensure that no installed add-ons will be lost, and end users will gain the ability to remove them if they chose to.

If you self-distribute your extension via sideloading, please update your install flows and direct your users to download your extension through a web property that you own, or through addons.mozilla.org (AMO). Please note that all extensions must meet the requirements outlined in our Add-on Policies and Developer Agreement.  If you choose to continue self-distributing your extension, make sure that new versions use an update URL to keep users up-to-date. Instructions for distributing an extension can be found in our Extension Workshop document repository.

If you have any questions, please head to our community forum.

71 responses

  1. hooffioff wrote on :

    Could you clarify please whether this means extensions can no longer be installed to the following directory on Linux, and that as a consequence it will no longer be possible to install my own personal extensions on my own computer unless I jump through hoops to get them signed by Mozilla?:
    /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}

    1. Jorge Villalobos wrote on :

      There are a few use cases on Linux that we’re still analyzing to figure out if they should still be supported or not. This one sounds like one we wouldn’t support because it would have the problems we’re trying to solve, but I couldn’t give you a definitive answer right now.

      That said, getting an extension signed for self-distribution is fairly straightforward, or you can also disable signature checks if you switch to the ESR distribution of Firefox.

  2. Anon wrote on :

    What if the user is going to have a browser and add-ons from the sources? Mozilla cuts off the opportunity not to get a binary add-on. Bastards.

    1. Jorge Villalobos wrote on :

      I don’t quite follow what you mean, but I’ll try to respond anyway. If you’re trying to build extensions from their source code and load them into Firefox (presumably with signing turned off), the only thing that would change for you is that those built extensions would need to either be loaded from the profile folder or from about:debugging.

      1. Anon wrote on :

        Mozilla will prevent getting add-ons through distribution repositories. I do not trust addons.mozilla.org.

    2. Earl Phlegm wrote on :

      Mozilla does more damage to their users trying to protect them than the bad guys do. I’m still using Firefox 51 because they ended support for an NPAPI extension I have to run. They could have left the NPAPI platform intact with a warning to use at your own risk instead of destroying the ability of perhaps millions of users to enjoy a particular benefit that caused them to choose Firefox in the first place. I guess they assume we’re too stupid to choose wisely so they decided to do it for us. Reminds me of most of our politicians. I won’t be voting for them either when they come up for re-election nor will I be choosing Firefox when I’m forced to abandon the old version I’ve hung onto for so long because it will no longer function with the modern web. Microsoft and Google terminated features widely used for profit, I assume. Firefox, I guess, does it under the guise of user safety. Considering the investment of time that a user puts into making a browser function in a way that is beneficial to them, terminating a feature, in my opinion, is like buying a car and then having the manufacturer disable it for some obviously ridiculous reason so you have to buy a new one. I might not have paid cash for Firefox, but it cost me a tremendous amount of money nonetheless. No more.

  3. zugu wrote on :

    Wow, now that’s some real doublespeak right there. You’re removing a feature, you’re removing control, yet you claim that by doing this you’re actually providing users with more control.

    Absolutely insulting and shameful behavior, Mozilla.

    1. Erin Dachtler wrote on :

      I feel like I might be the only one who read the post? So I’m going to try to summarize it real quick:

      Some programs (like Skype and Avast, as well as outright malware) install browser extensions for Firefox by placing them into a folder, which results in every user now having that extension installed whether they wanted it or not.

      This change makes it so that extensions will no longer be easily installable by other programs on your machine.

      You can still add your own extensions manually, or distribute them from your website just like you could before.

      What’s being removed is one installation vector that was being abused to forcefully install extensions that users may not have wanted.

      1. roderick35 wrote on :

        This is all rubbish.

        First of all, the extension is installed but is not enabled. The worst thing that happens is that the extension manager is cluttered with disabled extensions. But that’s hardly worse than the pile of extensions that Mozilla “recommends” to me.

        Second, if you install some shit program that installs extensions into your browser, than you have a much bigger problem already, which cannot be solved by “hardening” the browser.

        As usual as in the last few years when Mozilla took control out of the hand of its users, we get a red herring and the rest is buzzword bingo.

  4. Aaron wrote on :

    More control… by taking away functionality? BS. Why don’t you just rename to Chromefox and drop all the unique features that attract users

  5. Anonymous User wrote on :

    “To give users more control over their extensions, support for sideloaded extensions will be discontinued.”

    This is almost as good as the classic oxymoron: “Military Intelligence”.

    To serve your customers better, you will remove a useful feature, allegedly so they have “more” control over it.

    Question remains, did Google once again pay you to do this, or was this some internal initiative to be “innovative”?

    I am not sure how you expect anyone to take Mozilla Firefox seriously as an option for browsing the web, if you continue like this

  6. Merlijn wrote on :

    Wait, does this mean users will be limited to extensions available in the add-ons store?

    I’m not familiar with the terminology so but “support for sideloaded extensions will be discontinued” sounds to me like you’re locking down Firefox to only use extensions from the store.

    If this is not the case, please clarify that. Take a look at the comments section on hacker news etc., this is hurting your reputation really badly.

    1. Caitlin Neiman wrote on :

      Developers will still be able to self-distribute, and you will still be able to install extensions from self-distributed (non-AMO) sources. 🙂

      Going forward, developers won’t be able to distribute an extension through an executable application installer.

    2. Robert Berge wrote on :

      No, you can install addons from any source, you aren’t restricted to mozillas own store.

  7. Vivaldi wrote on :

    Will it still be possible to add an add-on locally by moving the file onto add-ons manager?

    1. Caitlin Neiman wrote on :

      Yes, this will still be supported!

  8. JM wrote on :

    Im wondering if this will affect selenium/webdriver based tests to automatically install addons to the profile via https://selenium-python.readthedocs.io/api.html#selenium.webdriver.firefox.webdriver.WebDriver.install_addon ?

    1. Jorge Villalobos wrote on :

      If they are installed to the profile folder, it shouldn’t be affected. The key factor here is whether the file is being added to a particular profile or a global location (I’m not familiar on how this tool does it).

  9. Fitipaldi wrote on :

    Please don’t do this!
    Can’t we reach a compromise, at least? What about keeping them like Firefox 73 forever?
    “Firefox will continue to read sideloaded files, but they will be copied over to the user’s individual profile and installed as regular add-ons.”

    The user case if obvious: you can setup a system wide policy that add value to all the system’s users, but let the power users remove/or add other addons.

    In the public systems I administer at the local library and at home, all workstations have Debian installed. I apt-get install some addons to provide better value and less tracking for the users but I have no problem with some of them customizing their experiences to their liking.

    It would be a lot of trouble if I had to login to each user account manually in order to install all the extensions that people already depend on.

    So please, please, leva us with the Firefox 73 option.

    Thanks,
    Fitipaldi

    1. Michael Kaply wrote on :

      When you apt-get install the extensions, where are they going on the system?

      I’ll be providing better way to do system wide Linux policy which will provide you a much better way to do what you are doing.

      1. Dominik wrote on :

        As a maintainer of distribution packages of Firefox add-ons, I’m confused. So far, it was possible to install a package which just drops the xpi file(s) in /usr/share/mozilla/extensions/{ext_id} and it would work for all users of a particular machine. What is the way forward if you take that away?

  10. Mark V wrote on :

    In my org, I’m usually the advocate for Firefox compat, while most everyone is happy with building Chrome-only stuff.

    And boy does it get harder with every update to advocate for Firefox. Useful addons that we once had, gone. Garbage apps get integrated into the browser. Customization options get deprecated and removed. Now this here crazy talk: “To give users more control over their extensions, we take away the ability to install extensions from users”. Walled garden much?

  11. Tan wrote on :

    If you’re gonna do this, at least leave power users an option in about:config to toggle this off they wish to. Now, that is giving the users control.

    1. Jan wrote on :

      I don’t think adding an override like this would solve the problem. An installer or malware could easily re-enable sideloading by adding the option to prefs.js or user.js files.

  12. gholms wrote on :

    How will enterprise users deploy extensions to workstations after this change?

    1. Michael Kaply wrote on :

      We have enterprise policies for deploying extensions to users:

      https://github.com/mozilla/policy-templates#extensionsettings

      You can also use the distribution/extensions directory.

      1. datenwolf wrote on :

        If you can effectively force an extension being installed and active by an enterprise policy, what sideloading used to do, wouldn’t that then be the logical sidestep for malicious actors to take?

        I for one was always happy that I could have the security and privacy essentialls (uBlock Origin, HTTPS Everywhere, Don F*** with Paste) sideloaded system wide for convenience. I’ll have to switch to policies then.

        P.S.: Your email form is broken, it won’t accept “blogcomment+mozilla.org@example.com” (replace example.com with my personal domain), telling me:

        ‘ The e-mail address you entered doesn’t look like a complete e-mail address. It should look like “yourname@example.com”. ‘

        I can assure you, that this address exists and accepts mail. Please fix your comment form to be RFC5322 compliant.

  13. cryptodropme wrote on :

    No one extension anymore?

    1. Caitlin Neiman wrote on :

      Extensions will continue to be supported in Firefox.

  14. Eric H. Jung wrote on :

    Most of the comments here are negative, so I wanted to add a contrarian voice: thank you for removing another attack vector.

    Eric Jung

  15. Khalil Santana wrote on :

    >> are unable to remove them from the Add-ons Manager

    That is precisely why people preload, it is not an sideffect, it is an useful feature for corporations, small bussiness etc.

    Otherwise, how Im i supposed to keep 1000+ PCs with the required plugins (ie Document Signing helpers) up and running?

    I agree users should have a say in what they run on their hardware. But if they are running on my hardware, they will run my software aswell.

    1. Michael Kaply wrote on :

      But they can still disable which makes it not useful at all.

      If you want to prevent users from removing or disabling addons, you can use policy.

  16. Ben Tyger wrote on :

    This method was often used for an organization that uses Firefox as an organizational browser and has a base set of required addons that need to be installed. Previously, admins could just drop an XPI into a well-known place in the filesystem and Firefox would load that XPI for every user that uses firefox. Also, this location would not be non-superuser writeable by default.

    With the new system, you can only install addons with user interaction (File UI or Web Store). Now users can choose not to install user required organization addons. Also, helpdesks will get more calls with users saying their X webpage isn’t working the way it used to because some extension is missing. Then the helpdesk person has to assist the user to install the previously auto-installed plugin. That’s a waste of time and money.

    The ‘insecurity’ comes from users installing shady software (authorized or not). When an application is installed on most OSes, you have to give the installer tempory superuser rights. That (shady) installer can drop a Firefox XPI into that well-known directory just as easily as an admin script can. The issue is untrusted software, not the XPI installer method.

    1. Ben Tyger wrote on :

      On further reading, this affects both the user-privileged cases and the super-user cases. I say get rid of the user-privileged methods but leave the superuser filesystem places available.

      Admins, who should have the knowledge to be smart about it, should know what should be installed and allowed what is in those sensitive locations. Standard users often can’t be trusted to make those decisions. From an exploit point of view, it is a lot more effort to get a scripted XPI installed as an unprivileged user to a superuser file location that someplace with the user’s own privileged filesystem space.

  17. Tessa wrote on :

    This is honestly such a terrible, terrible, terrible idea. This is definitely not the time for Firefox to be taking away user control over how they install and manage their browser configuration. I’m really disappointed in the Mozilla team responsible for this change.

  18. Anonymous wrote on :

    This title is atrocious and probably part of the reason people are getting so mad at you, you realize?

  19. Nonya Biznes wrote on :

    This means the true and final death of Firefox. Chrome(ium) is the only other choice and it’s even worse. Third party forks are so far behind they can never be considered secure.

  20. MJG wrote on :

    This looks like a move to increase surveillance of Firefox users, and prevent personal control over the browser.

    (If it isn’t please explain how.)

    If a user wants to build personal extensions that they don’t distribute, they seem to be toast.
    Any call that goes out on the Interwebs is monitored and potentially seen by a wide range of unwanted people.

    1. Caitlin Neiman wrote on :

      To be clear, developers will be able to self-distribute extensions on places other than addons.mozilla.org, and users can still install those extensions. This includes building and installing an extension just for yourself.

      Developers won’t be able distribute extensions that are installed upon an application install.

  21. Daniel wrote on :

    Wow good job on ruining firefox by removing the handy features differentiating it from other browsers like chrome.

    1. Bry wrote on :

      Except Mozilla has done this with your well-being in mind whereas Chrome does not and will try everything in their power to consistently track you in any way they can….

  22. Lou Sier wrote on :

    This is straight up stupid and the only reason why I’ve been supporting Firefox over Chrome, with their decision to limit what extensions you can and can’t install. As a developer I need to install my own extensions, and as a user I need to be able to have control over my browser. I’m uninstalling Firefox and looking at better alternatives.

    1. tbodt wrote on :

      There’s no change to what extensions you can and can’t install. You’ll still be able to install whatever you want through about:addons.

  23. A confused former fan… wrote on :

    I don’t get it. Chrome was just neutral, had full adblock capability not long ago. Firefox’s popularity was tanking. Now Chrome became the bad guy, trying to eradicate adblocks and lobotomizing extensions. Cool, finally Firefox has the spotlight – it can shine.
    They introduce a bunch of cool privacy features and such. Everyone is happy, people are coming back to Firefox.

    Now this happens. Why.
    You were supposed to be the good guys.

    Now I gotta wipe Firefox off and move to Vivaldi on all the workplace and deployed machines. It’s not the end of the world. Users lived after I moved them from Chrome, but… why? We want to support you. We want Firefox to succeed. But then you push away the userbase who actually spreads the browser.

    I have ZERO idea of what’s going on at Mozilla’s leadership.

    1. Herbert H Dupree II wrote on :

      As much as I am an unofficial evangelist for Vivaldi, do keep in mind that it is Chromium-based, so there are still some elements that could be part of the reason you left for Firefox as it’s not like Chrome for now. With MS Edge going to Chromium, as far as I know, Firefox is the only mainstream browser not tied to Google Chrome,

  24. sebboh wrote on :

    Jorge and Caitlin,

    I’m a fan and a donor. Looks like you upset people today and I’m trying to figure out how to avoid this kind of thing in the future. (As a former Netscape Navigator 3.0 user, I figure we’re kinda all in this together.)

    > To give users more control over their extensions, support for sideloaded extensions will be discontinued.

    You knew that phrasing would get all us mega nerds riled up, right? It’s doublespeak…

    Why not drop the corporate-ese language and say what really happened?

    You got data that shows extension sideloading is a major problem, right?

    What kind of problem? Malware? Piracy? Some future work depends on sideloading being removed? Tell us. We can handle it.

    You know power users don’t like using AMO. And thus, we’ll react negatively to the announcement. So… you considered that and weighed your options and decided that it was more important to go ahead and remove the feature. Right? Well, tell us. You’re smart, you probably made the right decision. Show us.

    Next time you see something like this coming, and can’t get out of it without hurting *someone*, explain your choice upfront. Don’t use doublespeak.

    And if you didn’t see this coming, you really should email me. I’ll get you in touch with some counterpart of mine who is an elected leader of a computer club or something, instead of just some rando like me. And you run future announcements by this person, and don’t get blindsided again.

    I want Mozilla to be successful. Firefox is the only non-commercial flagship browser left.

    1. Bry wrote on :

      You sir, are the only person who has laid out constructive criticism and it was a damn fine one too.

    2. Bry wrote on :

      My initial comment was rejected, so I’ll write again:

      Your comment is very helpful, I think. The folk at Mozilla need to take your advice for later posts.

      Regardless if this was intentional or not, this shouldn’t happen again. People are freaking out for valid reasons; they’re confused.

  25. GI_Jack wrote on :

    need this on linux as many distros including arch package firefox plugins as system packages

  26. Joshuah rainstar wrote on :

    You are doing this all wrong. This is why I use google chrome! you firefox nerds have no competence.

    Here is what you SHOULD do: institute a notification that pops up and asks users if they want to use globally installed extensions, with a list of them displayed , and all disabled by default, and include some kind of protected configuration option that allows them to set it to either disable the request or always enable global extensions, and include a variable with the installer so this flag can be set during install by sysadmins.

  27. Jul wrote on :

    Please stop destroying the best browser. This doesn’t give any control to users, this is just blocking our freedom to use the browser.
    I use small custom and not published extensions, what now?

    If security is a problem there are better ways to implement this than disabling sideloading, maybe making it opt-out or something.

  28. Z wrote on :

    What is this Mozilla ?

    I lost a translation add-on yesterday citing Remote Code Execution permanently broken and irreparable. Which uses Google API to translate a webpage saying this addon is malicious . Seriously you are crippling the end user with this draconian polices, I moved from Chrome after 8 years because on how restrictive they are from Padlock to uBlock Origin fiasco. And I loved how Quantum was made and perceived and to make it worse you guys even removed the whole Firefox branding image that you build over the decade.

    Now I see you executed the remote code and banned the whole damn Add-on to serve your purpose of Services model ? With that bloatware that is shipped in and how can we forget the certificate breakdown of the whole browser addons to oblivion and you shipped the malware studies enforced unless disabled like Opt-out policy instead of Opt-in.

    This is called blasphemy over your ideals and principles and user base.

    Microsoft is already moving ahead with Chromium. I’m 100% sure if you pursue this path of doing hypocrisy like Google you will end up dumped by all users and power users. Is Google paying you to do this ?

    A big fat middle finger to the users. This is very very unfortunate at your leadership decisions Mozilla. Look at ycombinator feedback.

  29. Lusito wrote on :

    Very appreciated! I always hated it when antiviruses or other software would install extensions in my browsers (usually resulting in instability or performance loss).

    I do get, however, that there are some use-cases, like company-managed extensions. Maybe you can create a feature that allows globally-installed add-ons in a safe way through system-administrators?

    For me it would also be okay, if upon sideloading an extension, I would receive a question if I want to allow this installation or not, resulting in the add-on being disabled until the user chooses to enable it.

  30. Unown wrote on :

    These changes break the best translation extensions, such as google_translate_this. I don’t these should have been done before the Mozilla translation service was released. Is there any information on when that will be done? This is a crucial feature for me and will be a dealbreaker if it is not implemented before sideloading is discontinued.

    1. no wrote on :

      Even after Mozilla’s own translation solution(which will likely be burdened by inexplicable design choices and ethical issues just as most of their major decisions in the past ten years have been,) people have a right to develop competitors.

  31. Evert Mouw wrote on :

    Could it break a lot of packages in the AUR? That would be really sad…

    https://aur.archlinux.org/packages/?O=0&K=firefox

  32. Juraj Mäsiar wrote on :

    Am I the only one actually happy with this change? 😀
    Desktop software should not be able to force me extensions I may not want!
    And for those who needs their own private extension, there is `web-ext` tool which can generate signed extension:
    https://extensionworkshop.com/documentation/develop/web-ext-command-reference/#web-ext-sign

    Piece of cake!

  33. Kai wrote on :

    Will the developer tool “web-ext” still work?

    1. Caitlin Neiman wrote on :

      Yes, web-ext will still work! In fact, a new version (3.2.1) was just released yesterday. 🙂

  34. Ste wrote on :

    We still build a Firefox installer with Xpi estension included?

  35. TheRave wrote on :

    What is with proxy folders with unzipped addon for development? I have my development folders on a separate HDD. From time to time i take also addons which was not developed by myself and make fixes if they are not maintained anymore. Specially since it is not possible anymore to use unpacked addons.

  36. Shibu wrote on :

    The article as well as the replies from the firefox team is not clearing telling us what this change does.
    Can you give an example of what actions are allowed and what are not?

    Are you saying that if user install skype and the skype installer drops an XPI in the firefox folders? Then it will install unintended addon?

    Consider this, if skype has write access on those folders, they can just replace firefox.exe with some other file . what are you going to do?

  37. Anu Kuruvilla wrote on :

    Hi,

    I have two questions:
    1. We are side loading extensions through registry hive now( HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Firefox\Extensions) Is this also getting banned.
    2. When you meant adding extension through an owned Web Property, I assume what you meant is that we can guide user to click on a button in one of our hosted web pages and get the extension installed. Am I right?

    Thanks
    Anu

  38. Stefan wrote on :

    @Earl Phlegm: I agree 100%. Luckily i stayed with 52.9 ESR. All telemetry blocked as well.

    Soon Mozilla will have a browser that only can be installed but not used at all….

  39. fettucini wrote on :

    Caitlin, why don’t you e. g. instead make only load xpi’s that got acknowledged and registered by the users themselves, on the next firefox start, where they’re presented with a list of new, yet unregistered xpi’s plus description / sha256 fingerprint, from which they can choose to remove, grant, or put ‘on hold’.

    The xpi / add-on control in place has some shortcommings with cryptic, non-descriptive directory entries and add-on / plugin remnants anyway; this way, you could fix that problem with a better xpi / plugin / add-on manager, too, that gives users more control over those.

    Another more complicated solution could be, to implement a permanently running ff-install-watcher daemon, that monitors attempts of installers side-installing xpi’s. Of course, this might require close collaboration with all the major OS distributions out there, to support some kind of hook intercepting such attempts and giving the user a choice whether to install away or not.

    I’m not exactly happy whith many of the (hidden and silently implemented) opt-out features Mozilla implemented over the last years (many api’s, experiments, telemetry, normandy and so on).

    Firefox and Thunderbird should really become more modular and customizable: at install-time users should be presented with a descriptive and categorized opt-in / opt-out menu, of which features they want to include. If they wanted, they should be able to install them in form of plugins later on, still.

    If you really want to give users more control, this might be a good start:

    Few can – and even fewer want to – investigate and hack away the badly documented ff registry, if not absolutely forced to (which, sadly, becomes more and more mandatory these days, because of Mozillas new intransparent top-down policy).

  40. miksuh wrote on :

    That is really stupid and awful decision. Well Debian used to have Iceweasel instead of Firefox, I am sure Iceweasel will now come back to Debian because of this decision. Debian 11 will mosst likely have Iceweasel, not Firefox.
    It is really stupid if you can not use extensions installed from the linux distroäs repository. I do not like that at all.

    By the way. Is that change already in use in the Firefox ESR 68? I have two laptops still running Debian 9 “Stretch”, I have not upgraded to Debian 10 “Buster” yet. I upgraded to FirefoESR 68 today because it is now available for the Debian Stretch. Firefox ESR 68 does not seem to load extensions installed from Debian repository. Everything worked just fine with Firefox ESR 60, but that Firefox 68 does not semm to use extensions (ublock origin) installed from Debian repository. That’s why I started to google about this problem and then I did find this page.

  41. miksuh wrote on :

    You guys do not seem to understand that you are causing bug trouble to users, especially to blind and aother visually impaired users like me. I am blind and I am using Debian and I know many other visually impaired Debian users too. If you really do what you say then users will suddenly notice that none of the extensions installed from the linux distro’s repo work and then you do not have any idea what is wrong. If you are a
    e.g visually impaired user then it is not so esy to figure out that you suddenly can not use extensions installed from the distro’s repository when you have used to do just that.

  42. .Eddie G. wrote on :

    Ok, so it appears a lot of people aren’t happy with this. I for one am neutral….in that, I use Firefox exclusively in my work and at home, but I’m not much of an “extension” kind of person, I mean aside from some themes, and uBlock/Adblock?…there’s not much else I need. BUT if this interferes with uBlock or Adblock in any way?…I’ll have to ditch Firefox for another browser, only because I am in the IT field, and I am constantly reading articles, and having to visit sites that are “pop-up / ad-heavy”. And I used to be unable to finish just one article due to all the pop ups and ads, but once I installed the uBlock and AdBlockPlus extensions?…I’m more productive than I’ve ever been! SO if the two “tools” I need the most won’t work anymore?…then this is goodbye Firefox, and it will be sad too, because I’m a strong believer in Open Source and helping the companies and organizations that work in it in any way I can. So maybe….if at all possible?…figure out a way to let the extensions that people may need to stay…and anything else gets “isolated” or placed in a different category / location so that if someone WANTS that extension….then they have to make a concerted effort to get it. This way….if/when something breaks?…you’ll be free of any accusations about it. It will be the classic “We Warned You Not To Do It” scenario…just a suggestion.

  43. goppi wrote on :

    If I understood correctly what your plans are in the future with deploying extensions we will drop Firefox ESR in our Enterprises (about 3000 users) completely. In a managed environment it is common that users do not have the ability to install anything in “%ProgramFiles% under Windows so there is no security risk exposed by the ability to sideload extensions by software deployment tools there.

    Secondly it is vial for keeping support efforts economical that user environments are in a defined somewhat static state where the user is not able to install any extensions at all. Administrators choose what groups of users will get what kind of extensions which are then deployed by software deployment tools.

    Sorry to say but when reading your plans I have to determine that you have absolutely no idea what are the needs of Enterprise customers.

    1. Michael Kaply wrote on :

      I’m not sure where you would go if you dropped Firefox – no other browser provides a feature like this. Chrome requires all add-ons be in their store.

      That being said, we are investigating keeping this feature at a system level for the ESR.

      In addition, we provide policies that provide much better control over installing/locking add-ons than sideloading does (you can still disable when sideloaded).

      https://github.com/mozilla/policy-templates#extensionsettings

  44. August wrote on :

    Using Selenium to install signed addons and temporary unsigned addons are still in need!