Mozilla Add-ons Community Blog
Categories: compatibility developers policy

Introducing Extension Signing: A Safer Add-on Experience

364 responses

Update: some of the details in the plan (particularly the timeline) have changed since this post was published. Please refer to this documentation page for the latest information.

This year will bring big changes for add-on development, changes that we believe are essential to safety and performance, but will require most add-ons to be updated to support them. I’ll start with extension signing, which will ship earlier, and cover other changes in an upcoming post.

The Mozilla add-ons platform has traditionally been very open to developers. Not only are extensions capable of changing Firefox in radical and innovative ways, but developers are entirely free to distribute them on their own sites, not necessarily through AMO, Mozilla’s add-ons site. This gives developers great power and flexibility, but it also gives bad actors too much freedom to take advantage of our users.

Extensions that change the homepage and search settings without user consent have become very common, just like extensions that inject advertisements into Web pages or even inject malicious scripts into social media sites. To combat this, we created a set of add-on guidelines all add-on makers must follow, and we have been enforcing them via blocklisting (remote disabling of misbehaving extensions). However, extensions that violate these guidelines are distributed almost exclusively outside of AMO and tracking them all down has become increasingly impractical. Furthermore, malicious developers have devised ways to make their extensions harder to discover and harder to blocklist, making our jobs more difficult.

We’re responsible for our add-ons ecosystem and we can’t sit idle as our users suffer due to bad add-ons. An easy solution would be to force all developers to distribute their extensions through AMO, like what Google does for Chrome extensions. However, we believe that forcing all installs through our distribution channel is an unnecessary constraint. To keep this balance, we have come up with extension signing, which will give us better oversight on the add-ons ecosystem while not forcing AMO to be the only add-on distribution channel.

Here’s how it will work:

  • Extensions that are submitted for hosting on AMO and pass review will be automatically signed. We will also automatically sign the latest reviewed version of all currently listed extensions.
  • Extension files that aren’t hosted on AMO will have to be submitted to AMO for signing. Developers will need to create accounts and a listing for their extension, which will not be public. These files will go through an automated review process and sent back signed if all checks pass. If an add-on doesn’t pass the automated tests, the developer will have the option to request the add-on to be manually checked by our review team. A full review option will also be available for non-AMO add-ons, explained further ahead.
  • For extensions that will never be publicly distributed and will never leave an internal network, there will be a third option. We’ll have more details available on this in the near future.
  • There will be a transition period of two release cycles (12 weeks total) during which unsigned extensions will only generate a warning in Firefox.
  • After the transition period, it will not be possible to install unsigned extensions in Release or Beta versions of Firefox. There won’t be any preferences or command line options to disable this.
  • Installation of unsigned extensions will still be possible on Nightly and Developer Edition, as well as special, unbranded builds of Release and Beta that will be available mainly for developers testing their extensions.

All Firefox extensions are affected by this change, including extensions built with the Add-ons SDK. Other add-on types like themes and dictionaries will not require signing and continue to install and work normally. Signature verification will be limited to Firefox, and there are no plans to implement this in Thunderbird or SeaMonkey at the moment.

What this means for developers

For developers hosting their add-ons on AMO, this means that they will have to either test on Developer Edition, Nightly, or one of the unbranded builds. The rest of the submission and review process will remain unchanged, except that extensions will be automatically signed once they pass review.

For other developers, this is a larger change. For testing development versions, they’ll have the same options available as AMO add-on developers. For release versions, however, we’re introducing the required step of uploading the extension file to AMO for signing. For most cases, this step will be automatic, but in cases where the extension doesn’t pass these tests, there will be the option to request a manual code review.

In the case of developers who want their extensions to be side loaded (installed via an application installer rather than using the usual Web install method) the review bar will be higher, equal to fully reviewed add-ons on AMO (with the exception of AMO content restrictions). This is a convenient installation avenue for software that comes bundled with an extension, for example an antivirus application that includes a Firefox extension that interacts with it.

One important improvement that signing brings about is that the extension install experience will be renewed and improved. Extensions that meet the full review standard will have a smoother and friendlier install experience, regardless of where they’re hosted. Here’s an early mockup of how this will work:

Installation flowThe plan is to have this system working, at least in the transition stage, in Q2 this year. So, we will probably introduce extension signing warnings on Firefox 39.

Discussion

We welcome comments on this post, but if you want to debate the merits of this plan, please do so in the add-ons user experience list. That’s where the people driving the project will read and respond to your concerns.

364 comments on “Introducing Extension Signing: A Safer Add-on Experience”

  1. Onno Ekker wrote on

    So this won’t make it in Thinderbird 38. Does this mean that it will take another year before signed extensions come to Thunderbird fourty something, or will it be included in a 38.dot release?

    1. Jorge Villalobos wrote on

      I doubt this will make it to Thunderbird at all. Extensions on Thunderbird should continue to work normally.

  2. Monica wrote on

    Congrats, it’s great to see this happening. Better UX and better security will lead to more trust in Firefox.

  3. Perfect Slayer wrote on

    Hi,

    I would like to know if all previous (older) versions of a reviewed add-on will also been automatically signed?

    Thanks!

    1. Jorge Villalobos wrote on

      The current plan is to only sign the latest reviewed versions. We might be able to sign older versions by request, if there are good reasons.

      1. Mathieu wrote on

        Compatibility with unmaintained add-ons ? You are basically arbitrarily deprecating all these add-ons.

        1. Jorge Villalobos wrote on

          If they are hosted and enabled on AMO, their latest reviewed versions will be signed. Otherwise, there’s still the possibility of forking them and getting the forks signed.

          1. Mathieu wrote on

            The non-enthusiast hobbyist will most certainly appreciate having to dig into the fork/submission process, or don’t you think he will just keep using either the dev build, or non-restricted older version ?

            I think the latter, because it is the path of least resistance.

  4. Mindaugas J wrote on

    It would be great if the discussion group was moderated in a timely manner.

    1. Jorge Villalobos wrote on

      Sorry about that, that should only happen when people post for the first time.

  5. Wolfgang Marcos wrote on

    I’m looking forward the implantation of this new security feature, I liked the non-limiting to AMO approach and believe developers with no bad intentions will find it good too.

  6. R Kent James wrote on

    Speaking for Thunderbird, we discussed that today in our regular planning meeting. I don’t think we have made any decision yet about whether this is something that we would like, but in any case we already have way too many critical things we are trying to do before Thunderbird 38. So we are unlikely to try to get this into Thunderbird 38 unless we are forced to do so (which it sounds like is not the case).

    We also could not give good examples of cases where addon malware has been an issue in Thunderbird. If anyone is aware of previous history of issues, I would like to hear about it.

    My own opinion is that we would probably try to use addon signing in the future if it is easily compatible with Thunderbird, but that needs to b discussed with others.

    R Kent James
    Chair, Thunderbird Council

  7. Gary5 wrote on

    “After the transition period, it will not be possible to install unsigned extensions in Release or Beta versions of Firefox. There won’t be any preferences or command line options to disable this.”

    Goodbye Firefox, it’s been a nice few years.

    1. Tyler wrote on

      Right under that it says

      “Installation of unsigned extensions will still be possible on Nightly and Developer Edition, as well as special, unbranded builds of Release and Beta that will be available mainly for developers testing their extensions.”

      If you’re a user that needs to use some .xpi that the developer is too lazy to get approved by Mozilla, you can just use developer edition indefinitely.

      1. Mathieu wrote on

        The problem is that Mozilla is gonna become the next Apple or Google, moderating away add-ons on subjective reasons. Even if you use the “do no evil” argument, it would be pointless, as it used to be Google’s argument.

        1. tomitu wrote on

          Rather they are protecting everyone from malware/adware/etc… Maybe you are making addons to change start page or search engine and this will harm your business?

          1. ShEsHy wrote on

            “Rather they are protecting everyone from malware/adware/etc… ” and anything they decide that they don’t like from here on in. If it were done only to protect from malicious code, there would be an option to disable it (even AV/AM software has an option to disable it/ignore/exclude…, and that’s much more important to a PC’s security than signed addons), but no, this is done solely to create a walled garden of sorts, where Mozilla is the gatekeeper that decides what you can or cannot use on your PC. If you trust Mozilla to know what’s good for you then fine, enjoy, but I don’t (I did somewhat before it started Chromifying Firefox and more or less abandoning Thunderbird (except for the mandatory Chromification), but not anymore), and if they think their userbase is so stupid that they can’t even be allowed to add any addon not approved by Mozilla, they can just go fuck themselves.
            “Individuals must have the ability to shape the Internet and their own experiences on it” my ass I guess.

      2. Jice wrote on

        And what about my own extensions ?
        I don’t want to make them signed as i’m the only user and I can’t change my professional browser to nightly build.
        Mozilla was to defend our freedom, it’s becoming new google.
        Don’t be evil Yeh ?

    2. Dan Veditz wrote on

      What add-ons do you need to install that won’t be signed? If you are developing add-ons why can’t you use the Firefox Developer Edition to do so?

      1. Viktor wrote on

        It’s about having a free browser, not one that is permanantly and mandatorily tied to a walled ecosystem.

      2. Gary5 wrote on

        I already wait a month to install Firefox updates so extensions developers will have time to catch up or figure out which new Firefox setting needs to be disabled. Otherwise, for example Firefox 34 breaks Flashblock and 35 breaks Adblock Plus. I often have to install extension upgrades from the developer’s site after I see a comment from the developer at the AMO site about Mozilla taking too long to review the new version. The article says: “we’re introducing the required step of uploading the extension file to AMO for signing. For most cases, this step will be automatic, but in cases where the extension doesn’t pass these tests, there will be the option to request a manual code review.” No, I’m not going to wait for Mozilla to complete manual code reviews before I can install upgrades. And I’m not going to live without this or that extension for several months either.

      3. Michael Kaply wrote on

        The problem with developing against Firefox Developer Edition is that you can create add-ons that don’t work in the current Firefox quite easily (I’ve done it).

        It’s best to develop against the current shipping browser so you don’t accidentally use features that aren’t available in the current browser.

        In addition, if you want your browser to work against the ESR (which you probably do), you especially don’t want to use Developer Edition.

        Developer Edition is an interesting idea but developing against what Firefox will look like in 18 weeks isn’t good for current business.

      4. Mathieu wrote on

        Developing code in a different environment than the production environment, and worse, forbidding running development (ie. unsigned) code in production environment, seem a rather poor engineering choice.

        It is only a matter of time before an add-on encounter a bug present in release FF, but not in debug FF, and there will be no way to track it down…

        1. Jorge Villalobos wrote on

          There will be unbranded builds of Beta and Release where developers will be able to test their add-ons. The only differences between those builds will be the signature checking and the branding (name and logo).

          1. Will wrote on

            Why is there this control-freak fetish going around these days? Apple and iOS, Microsoft and Modern, Chrome and their addons. Now Mozilla? Come on guys, don’t be so freaking unilateral.

          2. James Edward Lewis II wrote on

            The new unbranded builds might become my usual builds going forward; I don’t care so much about the Firefox brand as about the *freedom* of the browser.

            Will the unbranded builds auto-update the way the branded ones do? Will they use the same profile as the branded builds, or will they use a separate profile like Firefox Developer Edition?

          3. Jorge Villalobos wrote on

            They should auto-update and use the same profiles, yes.

          4. Mikhoul wrote on

            So if for my personal need in my network I need to use my OWN private add-on I will be able to install Unbranded builds on my computers (with no logo) and use my add-on like now ??

            Let me know to be sure before going further in decision for our browser.: If we stay with Firefox unbranded or completely change cause I’m tired of those change since 2 years from Mozilla.

            Regards

          5. Jorge Villalobos wrote on

            Yes, you’ll be able to continue using the add-on that way.

          6. ShEsHy wrote on

            And where will one be able to download unbranded builds?

          7. Jorge Villalobos wrote on

            We will announce that later on. They will probably be linked from MDN.

    3. Mike wrote on

      Yeah, not being able to disable this is the nail in the coffin.

    4. Frederic Bezies wrote on

      So you want so much freedom so you can be able to break your firefox profile with unfaithful extension ? Good bye.

      And never ask me to clean up your computer after you caught some malware.

  8. Ryan Nematz wrote on

    I do think this is a good idea, especially for those un-removable antivirus plugins, but I do feel there should be an option to disable this manually, in a way that other programs can’t interfere, such as a CAPACHA or some other human verification. I have a few add-ons that I made for personal use that I do not plan on sharing and would like to continue using them.

    1. Jorge Villalobos wrote on

      You have a few options for your add-ons. You can submit them for signing, which doesn’t require you to publish or distribute them in any way. The only people who might need to look into their code are add-on reviewers. If that’s what you mean by sharing them, then your options are to use Nightly, Aurora, or one of the unbranded builds of Beta or Release.

  9. Mike Harris wrote on

    “The intent is that there will not be a way to configure a release build to bypass this restriction, as that bypass would also be usable by malicious installers.”

    By preventing Firefox users from using any extension Mozilla hasn’t personally approved, you’re turning Firefox into an iPhone and AMO into the App Store. You’re going to severely amputate the add-on ecosystem and users’ add-on experience without any consideration for what end users actually want. Don’t be Momma Mozilla sitting coop over users’ choices; let us do what we want.

    1. Dan Veditz wrote on

      Right now end users are getting a lot of what they DON’T want — crapware foisted on their browser. We don’t want to limit what users WANT in any way. By funneling add-ons through our signing process we will have a way to revoke abusive addons. It’s an interesting thing that the most popular add-ons are hosted on AMO and won’t be affected by this policy one bit. The most widespread of the add-ons NOT hosted on AMO are nearly universally reviled. There are some well-loved niche add-ons not hosted on AMO who will have a few hoops to jump through–either using Firefox Developer Edition or submitting the addon to be signed–but millions of average users will have their suffering relieved.

      When you visit friends and family for the holidays how many of them have had abusive add-ons installed without their consent? For me it’s been nearly 100% of families who don’t have someone who works in the tech field.

      1. st wrote on

        “Right now end users are getting a lot of what they DON’T want”

        How do you know?

        1. Frederic Bezies wrote on

          Just look at top 10 on http://download.cnet.com/

          And search for malware like toolbars, adwares, and so on…

          You’ll be surprised.

      2. Daniel Miranda wrote on

        This does not at all address why Mozilla would be centralizing signing instead of using the standard trust chains that deemed acceptable for HTTPS without restricting user freedom and forcing hoops to use what has been Firefox’s greatest strength.

        It seems you guys severely underestimated the impact of this decision on the trust your users have place on Mozilla for all those years when you failed to find a technical solution to the problem.

        1. Adam Novak wrote on

          Mozilla has to centralize signing so they can exercise editorial control. HTTPS and even code signing certificates are issued to anyone who can pay and isn’t technically breaking the law with their software. Automatically installing your “exciting special offers” software as a difficult-to-decline option bundled with something claiming to be “Flash Update Installer Pro” is not technically illegal, but it’s still wrong, and Mozilla wants to do something about it at least as it relates to Firefox add-ons.

          I spend a lot of time every month uninstalling crapware that provides uninstallers. People didn’t intend to install this stuff on their computers; someone manipulated them into putting it there. When user education fails, you’re left with technical solutions that need to be strong enough to protect the user from the user’s own processes.

          I’d advocate some mechanism for allowing users to install their own CAs so that Firefox will trust them, but then the authors of crap extensions would just make their sideload installers authorize their own CAs.

          We will see how it goes.

      3. Joshua Rodman wrote on

        It’s extremely common for things that are hosted on mozilla.org, I have to install unsigned updates from outside of mozilla because your updates break them. I’d say half my addons I’ve had to install unsigned versions of to continue to do my job.

      4. Alexander wrote on

        So fucking what. I can just compile Firefox from scratch with this shit commented out if I already have an installer on someones machine. Or I can install a proxy and inject my ads there. Do you want to remove proxy settings now?

        You can’t fix stupidity, and you shouldn’t try when it’ll piss off your power users. One of the reasons I changed back to Firefox from Chrome was that Chrome did exactly this, just that you could can load unpackaged exensions. Now that the last good browser has gone to shit (thanks for the ads on my start page) it wouldn’t matter if I use Firefox or Chrome.

      5. Mikhoul wrote on

        There is ALREADY Chrome for these users…. No Need for a Chrome Clone !

  10. ANDY wrote on

    I use a hacked extension that is no longer available from the original author. So far, there is no other extension that replaces its functionality.

    EchoFon 2.5.2 for Firefox is a full Twitter client operating on their older unsupported API. Following is an XPI and source:

    https://onedrive.live.com/?cid=d7a621b6ed74a4c4&id=D7A621B6ED74A4C4!442

    https://gist.github.com/JaHIY/4483939

    1. Jorge Villalobos wrote on

      It shouldn’t be a problem for you to submit your forked version for signing. You should change the add-on ID to avoid problems, of course.

      1. Viktor wrote on

        What if you want to use personally modified addon where you do not have permission to publicly redistribute the modified source?

        1. Jorge Villalobos wrote on

          Non-AMO add-ons that are signed will not be hosted or distributed on AMO. You submit the file for signing, get the signed version back, and you can do whatever you want with it. It shouldn’t be a problem for your use case.

          1. Mathieu wrote on

            As hobbyists will certainly use the dev build to hack code in the first place, once they get a working code, I don’t think they will bother submitting it for review, as installing a dev build will certainly be overall easier than getting the code signed, especially if they don’t want to publicize the code. Even if you claim that there is no need to publicize the add-on to get it signed, somebody will have access to the code, and they might not be trustable.

            All in all, I wonder how long it will be until we see cracks to root FireFox…

  11. Ronnie wrote on

    What about SeaMonkey users? We routinely convert firefox extensions to work with SeaMonkey. This essentially kills that ability.

    1. Jorge Villalobos wrote on

      How so? Add-ons signed for Firefox should still work on SeaMonkey, and unsigned add-ons will continue to work unless the SeaMonkey team decides to implement signature verification.

  12. greg wrote on

    so now we’ll need to fork the project again and have another one of the million versions that just disables this? k

    1. Frederic Bezies wrote on

      Why forking it ? So, adding security and preventing bad extensions to be installed is a bad thing ?

      So, in real life, why using lock and keys to secure houses ?

      1. Mikhoul wrote on

        When I work to renovate my house or mow the lawn or anything around MY house I don’t lock the door to be able to go in go out as I need some tools, that’s why we NEED a disable mechanism.

    2. Mikhoul wrote on

      That’s exactly what I was thinking a fork exactly the same but without verification for add-ons.

  13. Alex wrote on

    Approved extensions only? That is absolutely garbage.

  14. Erik Harris wrote on

    Will the standards for “signing” be the same as the standards for hosting on AMO? The EFF’s popular extension, HTTPS-Everywhere, has apparently been deemed ineligible for hosting on AMO simply because they use a toolkit that AMO doesn’t like in its production.

    If this change means that HTTPS-Everywhere can no longer work with Firefox, this attempt to make users safer will very ironically make some users LESS safe while browsing the web.

    I guess it’s nice to see a step being taken to protect the stereotypical computer illiterate grandma from installing a malicious extension, but from the perspective of an experienced user who doesn’t want the occasional headaches of using a development version (I did it for years, and kept running into compatibility problems with a handful of extensions), this announcement sounds more like “we’re putting shackles on the user” than “we’re making Firefox better.”

    1. Jorge Villalobos wrote on

      The standards for signing are not identical as the standards for hosting. The standard for signing will be similar to preliminarily approved add-ons on AMO, and we’ll probably lower the bar a little since we wouldn’t want to block development of add-ons like HTTPS-Everywhere.

  15. puck wrote on

    I, and I think many others, would really prefer the ability to do something to disable this… uh… “feature.”
    I don’t want the (increased) instability of nightly, but I still want to run my third-party obscurely developed addons. User security is important and all, but not allowing users to disable it if they want to (and you could make it really obscure to make sure that they definitely want to) seems to be doing the walled garden thing and removing freedom for a “better” user experience.
    At least consider (if you haven’t already) adding a flag in about:addons to allow the user to enable the installation of unsigned addons.

    1. Jorge Villalobos wrote on

      Any settings we add that can change this are easily exploitable by malicious applications and add-ons. We considered several scenarios and decided that this was the way to go. You can use Developer Edition, which is more stable, or the unbranded builds of Beta and Release. The only difference is that the application name and icon are different.

      1. st wrote on

        This is similar to the no-way-out HSTS crap.

        1. Adam Novak wrote on

          Maybe you can install an unsigned add-on to change the name and logo back?

      2. Daniel Miranda wrote on

        Did you consider having a nonce encrypted with a master password to disable the signing requirements? It would avoid automated add-on installations , and you could still show a strong warning at each extensions’ install time.

        1. Adam Novak wrote on

          Signing the extensions on installation with a memorized private key, basically?

          That would work, until a malicious installer overwrote the user’s public key with its own, so it could sign its extension as having been authorized by the user.

  16. Michael Kovarik wrote on

    I agree with Mike. Security decisions shouldn’t compromise user freedom. I think that the transition period should be kept indefinately. Something like “warning: this extension is unsigned and may be insecure. Read more here.” should be enough for users to make their own decisions.

    1. Frederic Bezies wrote on

      Who reads warning ? It is like reading EULA… Boring and 99% of people will bypass them.

  17. Vladmir wrote on

    I am curious about the decision to not include an option to re-enable functionality without going through the trouble of installing a second, unstable and/or unbranded browser. Is an average user managing to find their way into about:config and then find and enable the proper option that big of a concern? Or is there something else I’m missing?

    1. Jorge Villalobos wrote on

      There are various online guides that give users bad advice, like how to disable the blocklist, and people follow them without considering or understanding the consequences. There’s also the fact that malicious add-ons and applications can easily manipulate those settings.

      1. Gary5 wrote on

        “various online guides that give users bad advice, like how to disable the blocklist”

        You mean the blocklist that installs a Google PREFS cookie I can’t delete? I was amazed when Google maps zoomed to my work location in America while I was using a VPN in Switzerland. Luckily, it only took me about three hours to track down what was causing it and some bad advice on how to disable it.

      2. Jean wrote on

        So this is a Boolean system? Either add-ons are trust or not trusted. The structure of trust is based on the Mozilla security model. The specific goal is to actually to identify add-ons that are not trustworthy based on the code auditing and history of these. Trusted add-ons may violate expectations of privacy because privacy and behavioral advertising are not part of the Mozilla definition of trust.

        Thus if people download add-ons from their employer, bank, or any other entity which they in fact do trust, Mozilla will tell them it is untrusted. While if an add-on that tracks your browsing or location os downloaded from a “trusted” id Mozilla will tell people that it is A OK. However, non-technical cognitively-overloaded (meaning the vast majority of people) are then expected to understand the concepts of identity and cryptographic authentication in order to accept these assertions as themselves trustworthy.

        I do not think we agree about the models people have of security, privacy, or risk. In fact, from what I can tell, we have some profound disagreements.

  18. Anon wrote on

    I’ve been using and advocating Firefox for 10 years, since the very first version.

    Despite all shortcomings, it was still a browser that placed the user in charge.

    But now you’re making that go away too.

    Goodbye, Firefox. It’s very sad to see you become what you’re becoming. I’ll be looking for alternatives now.

  19. Mike wrote on

    This is a very bad idea.

    What attracted people like me to Firefox was it openness and the fact that it was not locked down like other browsers and software. I and many others then evangelized Firefox to regular users leading to its wide adoption.

    This is yet another step in the wrong direction for Mozilla after the Australis debacle.

    Making the browser yet more Chrome-like will not help regain users, and will not help your goodwill. People like me who evangelized Firefox over the years no longer do. I’m probably responsible for at the very least a few hundred people starting to use Firefox over the years.

    Now the opposite process is occurring as I no longer recommend it to anyone, and this will continue as long as the bad decisions do.

    Someone should hire some people with a better sense of the Firefox community at Mozilla. Really, this is getting dire.

  20. Kohei Yoshino wrote on

    Published Japanese translation: https://dev.mozilla.jp/2015/02/extension-signing-safer-experience/ 🙂

    1. Jorge Villalobos wrote on

      Excellent, thanks!

  21. mcdavis wrote on

    What are you thinking will be the turn-around time between submission and getting back a signature/signed version? More-or-less-instant, same-day, or best effort?

    Or maybe the question should be, have you established any kind of worst-case turn-around time that represents acceptable behavior in the new plan?

    1. Jorge Villalobos wrote on

      If your add-on passes all tests, the signed version should be available immediately. If it doesn’t and you request a manual review, then you should expect a couple of days of waiting. We are planning on scaling up to deal with the increased workload and we want these reviews to be as quick as possible.

      1. Anonymous wrote on

        >If your add-on passes all tests

        What will those tests be? What if someone wants nightly builds of an addon that won’t pass your automated tests (e.g. due to containing native code?), will you have the capacity to deal with that?

        1. Jorge Villalobos wrote on

          Add-ons that don’t pass the automated tests can be submitted for manual review. We will be much more lenient than we are on AMO, since our purpose is to block malware distribution, not police code quality.

  22. Boris Gjenero wrote on

    I find the lack of a way to switch this off in an ordinary release build very disturbing. I thought Mozilla respected user freedom, and I’m very disappointed.

    I realize that adding an about:config option to disable this would allow malware to override it easily. However, there are other ways that such an option could be set safely. You could rely on something that only an administrator could access, such as a file in the same folder as the Firefox executable. If malware is able to modify that, then malware could replace Firefox with a different build or apply a binary patch to disable signing. So, an off switch like that wouldn’t compromise security.

  23. Patrick Huy wrote on

    Previously it was easy to “patch” already installed Addons as a user by modifying their files. I assume this will make this impossible without using a “unbranded” or “development” build?
    Will this also mean that every add-ons signature is checked upon startup of Firefox (and probably the firefox js components themself)? Won’t this be a performance Problem?
    If no such checks happen wouldn’t malicious installers just patch already installed addon/firefox to inject their functionality?

    1. Jorge Villalobos wrote on

      Forked add-ons can be submitted for signing as long as you also change the add-on ID. My understanding is that there will be signature verification at runtime, but I don’t think it’ll block startup.

  24. Disappointed wrote on

    Pfft. If your aim is truly protecting users you can simply make this the default while giving advanced users an about:config option to opt out. Why do I need Mozilla’s permission to install an addon? Can’t you see this power will inevitabely get abused by corporations and governments?

  25. Jörg Behrmann wrote on

    Although I welcome the idea of signing addons in principle, I have to say that the current plans are a horrible idea. Setting Mozilla up as the sole trust entity sounds unwise. Not only would every developer need to go through Mozilla to get his possibly private addon signed, but it also sets Mozilla up as a single point of failure, meaning that a malicious entity could steal or otherwise compromise the key and sign whatever it wishes.
    It would be preferable if there was an option to add keys to ones keyring, so that I can explicitly trust myself or developers from whose repositories I build most of my addons.
    In that sense I also don’t see using a developer edition of Firefox as a solution, because signing _is_ a good thing and I want all my addons signed and not bypass the signing step.

    1. Adam Bolte wrote on

      Exactly this. I truly appreciate having signed add-ons, but this implementation is worse than not having it it all. If I trust a developer of a given extension, I should be able to add the key of that developer and not require Mozilla as part of the equation.

      What if I create an add-on for use in my corporate environment which has strict policies against outside code distribution (where submitting code to a remote server for any purpose would be in clear violation)? We won’t be able to deploy Firefox to corporate machines going forward, when the solution *should* have been to simply sign the add-on with my key, and roll out my key as part of the corporate machine image.

      Take a look at the F-Droid approach, where developers can add their own signed repository – this is what should be done here. Instead, you’re taking the Google overlord approach, so I’m now losing even more trust in Mozilla.

      Signed extensions should also not be mandated – especially for add-ons that the user already has installed. Are you just going to go ahead and uninstall them from Firefox installations when a specific release comes along? That’s BS – the user already trusts them! The user should always have the option to add an exception to the rule (possibly after clicking past a scary warning) so add-on X does not require Mozilla signed approval (while keeping it mandatory for other add-ons).

  26. nik wrote on

    Will you sign old addons on a user’s request, e.g. when extension is abandoned by its author but still useful?

    1. Jorge Villalobos wrote on

      If you submit the add-on for signing with a new ID, it’s no problem.

  27. someone wrote on

    This sounds like a huge PITA for developers who wish to test their addon versions on release Firefox without submitting it for signing after every minor edit/fix. Or to people who wrote a small personal addon of few lines and wish to run it on release Firefox.

    1. Jorge Villalobos wrote on

      Running different versions of Firefox for testing is fairly standard practice for developers, so it shouldn’t be a problem to have an unbranded build of Release or Beta to use for testing.

      1. Joshua Rodman wrote on

        This is false.

        Firefox is incapable of handling foreign preferences safely across versions, and is incapable of trivially (user-safe) splitting preferences stores by version.

        Therefore it is best to in your casual user environment (which you will frequently use for development purposes), use the production browser.

        1. Jorge Villalobos wrote on

          Can you elaborate on this? What do you mean by foreign preferences?

          1. Joshua Rodman wrote on

            If you run newer/older revisions of firefox, it mangles the preference data in ways that affect the other versions of firefox that you run. There are longstanding (decades!) old failures in this area that cause running more than one version of firefox to be a fundamentally unreliable proposition.

            As a result, the only way to do things like “test with unbranded” in a safe manner is to have multiple OS-level user accounts to isolate firefox’s datastores by version. That or in automation environments you can roll back the firefox volatile directory state for every test but even this is more or less unworkable because you’d have to maintain that very carefully across firefox versions which come so rapidly.

            Maintaining multiple user accounts is excessively cumbersome and error prone unless automation is used. Thus this whole thing results in being hostile to reasonable small-developer testing practices, despite your claims to the contrary.

          2. Jorge Villalobos wrote on

            Are you talking about running multiple versions on the same profile? Why not run separate profiles instead of separate user accounts?

      2. finger wrote on

        I’m not a developer and I have a few unmaintained addons that I need to tweak every once in a while. I also work on a box that has the normal firefox available but not the developer edition.

        I like the idea of signed addons very much but not being able to disable this is a serious PITA.

  28. mcdavis wrote on

    Does this have an effect on installing add-ons while offline?

    Does/will the browser need to be online at the time the add-on is installed?

    How does/will the browser verify the signature of an add-on being installed? Does the add-on contain its signature (leaving open the possibility of faking it, although hard to do if the signature is long enough), or is that recalculated for the add-on being installed at the time of installation ? When comparing against known good signatures, does it compare against a list cached locally or does it always ask AMO?

    It sounds like you won’t be able to install add-ons (signed or otherwise) in a profile that’s never been online, with release or beta, is that right?

    (The answers may be above, I’ll reread.)

    1. Jorge Villalobos wrote on

      Good question. Indeed, I forgot to mention that. The add-on file will be digitally signed, which means that it is extremely difficult to fake and you don’t need to be online in order for the verification to work.

  29. Dwyn wrote on

    Let’s say I only change the translation of an add-on or add a new translation and I am not the original author of the add-on, so I won’t upload this modified version to AMO. Is there a new signing for the modified version needed?

    Thanks.

    1. Jorge Villalobos wrote on

      There are a few options. You can change the add-on ID and submit it for signing, which doesn’t require hosting or distributing the add-on on AMO. If all you want is to test it (if you’re a translator on Babelzilla, for example), then you can use the unbranded builds of Release and Beta, or use Aurora or Nightly.

      1. Dwyn wrote on

        Thanks!

        Is changing the add-on ID *recommended* to avoid conflicts or is it *necessary* (either for the same resaon (to avoid conflicts) or for technical reasons)?

        1. Jorge Villalobos wrote on

          It is necessary, since the original owner of the add-on will also submit it for signing (assuming the add-on hasn’t been abandoned) and then the add-on ID will be tied to that developer, which is another important benefit of the signing system.

          1. Dwyn wrote on

            Thanks, no further questions! 🙂

      2. Mikhoul wrote on

        Does Unbranded Version will be available in French and other languages ?

        1. Jorge Villalobos wrote on

          That’s a good question, and I’ll look into it. I’ll include the answer in a followup post.

  30. SammysHP wrote on

    Well, I need local signing for one of my add-ons. I’ll use that machine for development often without internet access and need to compile/pack and install own add-ons. It uses (and will use!) the normal Firefox version, no beta, no aurora, no developer build.

    Please add an option to disable this “feature” or a way to use an own certificate that can be used to sign the XPI and set as trusted in Firefox.

    1. Jorge Villalobos wrote on

      Using the unbranded build of Release would be the easiest approach in this case.

      1. SammysHP wrote on

        But there are a few issues with this:

        a) This “unbranded” version is not available via the package manager of the Linux distribution.
        b) The system administrator won’t install any other version and I won’t install it as a user.

        1. Jorge Villalobos wrote on

          We’re still working on the details for enterprise deployment, which we know are an important segment of add-on users. This post only mentions this case briefly.

  31. Minh Nguyễn wrote on

    What will the automated review process for non-AMO extensions consist of? Will it be similar to the validation currently performed on AMO submissions? My extension triggers a lot of false positives in this validator. (For example, every services.sync.prefs.sync.* preference in the defaults/preferences file triggers a warning about a “potentially dangerous” pref() call.) Hopefully the bar for getting an extension signed doesn’t depend on this validator.

    Waiting a manual review could be problematic, too. Although my extension is hosted on AMO, many of its users end up installing updates before the AMO review team gets a chance to review them. As an input method extension, the extension frequently receives compatibility updates as third-party websites change. But AMO has in the past taken months to review these updates, so I’m forced to direct users to the beta channel on AMO or the unreviewed version on my website. Presumably the wait time will only increase as the more complex non-AMO addons get added to the queue. Will the extension’s beta channel at least be exempted from the signing requirement?

    1. Jorge Villalobos wrote on

      The automated process is still being defined, but it will be similar to the validation we do for AMO. However, it will be focused on security issues and we’ll make sure to minimize the tests that cause add-ons to go through the manual review track. We are planning on scaling up our reviewer team in order to deal with the increased workload, and we want the manual reviews of non-AMO add-ons to take a couple of days at most.

      Beta versions of add-ons will still need to be signed, and will fall in the same category as non-AMO add-ons (if it passes validation it’s no problem, otherwise you’ll need to ask for a code review).

  32. Yaqoob Jamil wrote on

    This is ridiculous. I write and use my own extensions and I share it with others.

    Why don’t you give us options to override this?

    1. Mathieu wrote on

      I guess this is Mozilla’s version of “do no evil”.

  33. toady wrote on

    What if a person creates a fake code signing certificate and installs the certificate in to the end users computer that the addon is signed with, Is there a restriction on the certificate accepted by the addon manager or does it accept any valid code signing certificate.

    Can this certificate exception be bypassed by and preference or setting as in who its signed by.

    I think this is a great and welcome change but i do have concerns about wait periods on reviews, Some addon reviews can take some time days, even weeks some even months how will this affect the users been able to visit the version section of the addons page and install the newer version while waiting for the review, The version could contain bug fixes that are important for that addons ability to function.

    Is there going to be changes to the review system to improve this.

    1. Jorge Villalobos wrote on

      The system is designed so it only accepts our signatures. A sufficiently privileged malicious application could modify Firefox to override this, but at that point your system is already compromised.

      There won’t be any settings that can override this.

      The review process for non-AMO add-ons will be different. It will be mostly automated, and the manual reviews will be as quick as we can do them.

      1. toady wrote on

        Thank you for the clarification Jorge.

        Few more questions, How will this affect 3rd party distributions, Take for example the use of the distribution folder with unpack addon in Firefox install directory.

        Since the addon is unpacked how will the new mechanic affect this.
        Example: C:\Program Files\Firefox\distribution\bundles\\
        https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Customizing_Firefox

        Will it require the addons to be packaged and singed or is there an exemption from this style of addon distribution.
        Example C:\Program Files\Firefox\distribution\bundles\

        There are currently ways to bypass the addon installation user interaction mechanic that allow people to silently install addons and enable them without user interaction, Can these still be exploited with a non signed extension or will these areas be address and no finally longer work.

        1. Jorge Villalobos wrote on

          Add-ons in the bundles directory are still supported. They will still need to be signed, but they can be unpacked (after signing).

          1. toady wrote on

            Thank you for the clarification Jorge,

            However this will add a large development overhead to project development having to constantly be submitting addons for signing and waiting for the addon to be approved for signing we affect the development of our products as it will take a large percentage of time away from development.

            “Add-ons in the bundles directory are still supported. They will still need to be signed, but they can be unpacked (after signing).”

            Doesn’t unpacking the addon after it was signed defeat the purpose of it begin signed as it would break the signature unless your just checking the SHA512 of every file to ensure no modification after signing, I can see many potential issues in this, Not to mention endless headaches when deployment of the addons fail due to the addons files hash might change for unknown reasons on the end users pc.

            This will also affect users who like to use the latest development builds of addons on github, The developer would have to get the addon signed just for user testing again adding development overhead.

            While i do support an improvement to help reduce the level of malicious addons, But this change will affect developers is a large way and potentially hurt the addon development for Firefox in a very negative way, As i can see many developers embracing the change but over time the repetitiveness and issue in toe from this they will begin to resent there embrace of such a feature, As this change not only affect mozilla and its market share but it affects companies who develop addons or use addons with in there companies.

            I do hope you can provide a new blog post with more clear and concise information as the current leaves too much room for interpretation and miss information and will only confuse and anger the masses.

          2. Michael Kaply wrote on

            This is incorrect.

            Extensions in the distribution/extensions directory will need to be signed.

            Things in the distribution/bundles directory are a completely different beast.

      2. Jim wrote on

        Why not just make it the policy that unsigned addons will require administrative privileges to install?

      3. st wrote on

        “but at that point your system is already compromised.”

        pretty much nullifies the whole security “argument”.

  34. bobby wrote on

    yay, looking forward that walled garden experience you can usually only find in chrome or OS X

    1. Mathieu wrote on

      I have no idea what you mean about Chrome, I can easily hack extensions to remove annoying ads.

    2. st wrote on

      Chrome doesn’t allow easy install of random extensions, but it’s still POSSIBLE.

  35. Piro wrote on

    I basically agree to this decision, but I’m afraid of applying of current review policy to all addons. I think that the review policy just for signing should be different from the one for “public” addons on the AMO website.

    For example, some my addons were rejected by AMO editors because they use “eval()” to inject code to existing function. On aAnother case, my addon using a library “JSDeferred” (similar to Promise.jsm) was also rejected because “it is not a standard way on Firefox”, even if one of JSDeferred’s features (not implemented in Promise.jsm!) is required.

    Both reasons of those rejection are agreeable to keep AMO website clean from such hacky addons. However, if privately hacked addons like ANDY’s one (described at https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/comment-page-1/#comment-212519) are also rejected to signing based on the review policy, I have to give up to use Firefox with my addons. If the purpose of this new signing system is the safety of people, the current review policy looks too strict for me.

    How do you think?

    1. Jorge Villalobos wrote on

      The review level for non-AMO add-ons will be similar to the preliminary review level, even slightly lower. We only want to make sure add-ons are safe.

      1. Piro wrote on

        Thank you for the answer.

        I have one more question. For my customers, I provide customized version Firefox with addons installed into distribution/bundle/ ( https://developer.mozilla.org/en-US/Add-ons/Extension_Packaging#Including_add-ons_in_a_customized_application ). Is this installation way also restricted?

        1. Jorge Villalobos wrote on

          Add-ons in the bundles directory are still supported. They will still need to be signed, but they can be unpacked (after signing).

          1. Piro wrote on

            Thanks, so, do you mean that unpacked addons under distribution/bundles/ will be controlled by the addon manager in the future? (Currently such addons are uncontrolled and just registered as parts of Firefox itself, because they are detected by an legacy module nsXREDirProvider lower than the addon manager.)

          2. Michael Kaply wrote on

            Piro:

            distribution/bundles or distribution/extensions?

            distribution/extensions need to be signed. distribution/bundles is different (not truly extensions).

          3. Piro wrote on

            Yes, I told about distribution/bundles. I’m worrying about the impact of this decision for the integration feature, because it is very similar to extensions.

          4. Michael Kaply wrote on

            The long term plan is for distribution/bundles to go away.

  36. mw wrote on

    This is the end of FF as FOSS. My freedom to change the software will be restricted due to mandatory signing. It will be no longer free.

    If it will be implemented FF is no more a choice for a browser.
    Good by and thank you for the fish. Good luck FF.

    1. Will wrote on

      To be fair, this does not disable your ability to change Firefox. Changing addons may or may not be permitted by the license on the addon itself, which isn’t necessarily GPL…

  37. nicu wrote on

    Sorry, but I disagree.
    While I am just as feed-up with malware sneaking trough extensions into the browser, I think this is a bad move and hurting freedom and openness. Make the user go to an extra step, scare him with a warning or such, but let hit run the damn software if he wants so.
    Forcing every extension to be signed would be akin Microsoft asking for every .exe to run on Windows to be signed by them or Google asking for every package to be installed on Android to be signed by them.

  38. AnonCoward wrote on

    I fail to see how requirement to submit all addons to Mozilla is anyhow better than requirement to distribute all addons via mozilla’s channel. Result is essentialy the same: now mozilla is single point of failure and grand centra authority, with no means to override.

    So Mozilla principle #5: “Individuals must have the ability to shape the Internet and their own experiences on it” is now a misnomer. They only have this ability IF approved by mozilla.

    Now Mozilla is a concentration camp where only some chosen few have rights to decide what is right and what is wrong, denying others similar rights. Welcome to walled garden, apple-style ecosystem, dear devs.

    Speaking for myself, I think it is time to change browser for me. Mozilla now just as restrictive as apple and so on. That’s not Mozilla I knew when I started using it. It is some hostile foreign entity, overruled by walled garden lowers.

    1. Emiliano Heyns wrote on

      What’s different is that you don’t have to go through the glacial review process, I hope. I don’t host my plugins on AMO because I got fed up with the weeks of delay for publishing simple fixes. I thoroughly hate this idea. Just give me a revokable key so I can damn well sign my work offline.

      1. AnonCoward wrote on

        > What’s different is that you don’t have to go through the glacial review process
        Cool. But worth of nothing for me, because I simply do not need browser where Mozilla would have exclusive control over what I install to my browser. Sure, I can use dev versions and so on, but it’s not like if I’m in mood to do free testing to those who proven to be just bunch of abusive apple-style tyrants. Generally I no longer trust Mozilla as software vendor as they completely departed from their initial goals and policies. These are no longer bunch of innovators who were promoting open web and open standards. Now they implement DRM, install some h.264 codecs without even asking me about that, and overall, they’re trying to be just cheap chinese fake clone of Chrome, ranging from look and feel up to internal architecture.

        And now what? They put ads on new tab page and supplied unusable default search engine. Then they’re about to be even more restrictive than Google in terms of sw install? Oh snap, I think they got infiltrators to remove them, just like Elop killed Nokia. I can’t understand why Mozilla thinks its fun to pwn users and now also devs. But I bet it will cost them market share one more time.

  39. AnonCoward wrote on

    P.S. Benjamin Franklin once told those who would give up essential liberty to obtain little temporary safety, deserve neither liberty, nor safety. He wasn’t Mozilla user but still counts as very good description of what’s going up.

  40. Nils Maier wrote on

    Please note: This is not a troll, but serious questions.

    Will AMO allow me to sign a hosted or non-hosted add-on that disables the signature enforcement in Release/Beta builds? I’m talking about an add-on that is not a malware loader, but an add-on that essentially would restore the previous behavior.

    What about other add-ons that basically enable side-loading of “add-ons” without signature checks, such as Greasemonkey/Userscripts or dotjs?

    Will mozilla sign add-ons that are illegal to distribute in the US, but might be legal in other jurisdictions, such as add-ons circumventing certain types of DRM, add-ons features certain types of content (e.g. “obscene” content)?

    Will mozilla enforce DRM requests even for add-ons from jurisdictions not in the US?

    Will mozilla enforce other lawful (in the US) requests, such as National Security Letters or FISA court orders against non-US add-ons?

    Will mozilla be allowed to sign and actually sign add-ons originating from authors in embargoed countries, such as Cuba or the Iran?

    1. Jorge Villalobos wrote on

      > Will AMO allow me to sign a hosted or non-hosted add-on that disables the signature enforcement in Release/Beta builds?

      Probably not. If we could ensure that it won’t be broadly distributed (say, it’s only for personal use), maybe. The problem would be to have some website say “install this to enable all add-ons!”, which would partly defeat the purpose of this initiative.

      > What about other add-ons that basically enable side-loading of “add-ons” without signature checks, such as Greasemonkey/Userscripts or dotjs?

      They’re still allowed, at least the ones we know about.

      > Will mozilla sign add-ons that are illegal to distribute in the US, but might be legal in other jurisdictions, such as add-ons circumventing certain types of DRM, add-ons features certain types of content (e.g. “obscene” content)?

      Yes, AMO content policies won’t be applied to add-ons that won’t be hosted on AMO.

      > Will mozilla enforce DRM requests even for add-ons from jurisdictions not in the US?

      Do you mean DMCA requests? Since we’re not listing or hosting these add-ons in any way, I don’t think it applies, but I am not a lawyer.

      > Will mozilla enforce other lawful (in the US) requests, such as National Security Letters or FISA court orders against non-US add-ons?

      Mozilla can’t reject such “requests”, as far as I know.

      > Will mozilla be allowed to sign and actually sign add-ons originating from authors in embargoed countries, such as Cuba or the Iran?

      We actually host add-ons from both of those countries on AMO, so I don’t think there’s a difference when it comes to signing them.

      1. Nils Maier wrote on

        Yeah, I meant DMCA requests but types DRM requests.

        It actually makes me a bit worried that your answers in particular to my legal questions are not answers at all.
        I’d like to see mozilla actually consult their lawyers to discuss and clarify legal issues such as the one I brought up and give definitive answers before the system goes public.

        >> Will AMO allow me to sign a hosted or non-hosted add-on that disables the signature enforcement in Release/Beta builds?
        > Probably not. If we could ensure that it won’t be broadly distributed (say, it’s only for personal use), maybe. The problem would be to have some website say “install this to enable all add-ons!”, which would partly defeat the purpose of this initiative.

        OK, thanks, full-fledged walled garden with arbitrary rule enforcement it is then. You already know my strong opposition to this whole “system” from previous exchanges, so I won’t reiterate…

        1. Jorge Villalobos wrote on

          I’ll bring up the legal issues with the right people. I know how you feel about this, so thanks for all the feedback.

      2. Anonymous wrote on

        > > Will AMO allow me to sign a hosted or non-hosted add-on that disables the signature enforcement in Release/Beta builds?

        > Probably not.

        Sounds like mission creep from the start. You’re saying you *only* want to block malicious behavior and apply even lighter review criteria than AMO preliminary reviews.
        And yet you want to outlaw specific types of features, even if they have non-malicious uses.

        You’re essentially saying that even a fully informed user won’t have the freedom of choice in a release version.

        1. Jorge Villalobos wrote on

          Well, a clearer way to state this is that we don’t want anything malicious or that can subvert this system.

  41. lee wrote on

    I am a deveoper,I user released version only,and I make many addon-ons for personal use,why should I upload the addon.Firefox is no longer free as beore since the new UI copyed chrome. And now,MOZ want to control the addon-ons like google,but the addon in chrome webstore is really safe?

  42. Samuel Bronson wrote on

    As much as I like the idea of signed add-ons, this really won’t be nice to those of us who want a stable browser but still sometimes want to try out pre-released addons, or — hey — *old* addons that aren’t on AMO.

    Couldn’t you just make the dialog more annoying and scary, maybe add some big red triangles and huge exclamation points?

  43. Daniel Miranda wrote on

    This is contrary to all of Moziilla’s values over the years. All the talk of openness and then turning the browser into a walled garden is unacceptable. I’ve been a Mozilla user for about a decade and this is absolutely hearth-wrenching and a terrible decision. It is not compatible with anything Mozilla has stood for. It is a political solution masking over a technical failure of Firefox to properly sandbox it’s addons.

    Why not implement the signing restriction just for automatically installed addons, and let it be overridden on manual installations? Or maybe tying an opt-out to a FIrefox account login so it cannot be faked by installers? Anything would be preferable to this.

    1. Daniel Miranda wrote on

      Also, what about the existing PKI infrastructure? Why should Mozilla be the only ones to hold signing power instead of allowing custom selection of trusted roots, like what is deemed acceptable for web browsing? Nothing about this decision makes any sense and sounds like a rushed solution brought upon by collective failure to apply long-term reasoning and regard for Mozilla’s mission.

      1. Jice wrote on

        As always… Mozilla has grown and has changed side.
        I’m really disappointed in this decision… I used this browser since the very first version and never changed just because of freedom it offered.
        And now ? What other browser can be used ?
        Sad day….

  44. peha wrote on

    you do it wrong Mozilla
    centralized trust is no trust
    you give yourself too much power you’ll not be able to handle

  45. Capt wrote on

    Approved extensions only?
    I’m absolutely against!

  46. blah wrote on

    Dear Mozilla,

    Go fuck yourselves.

    Signed,
    Everybody else

  47. Bohwaz wrote on

    I’m running an independent addon store. We have our own review process and policy. Will mozilla allow my users to add a signing key to firefox, or sign an addon that would add this signing key?

    If not it would mean users will have less choice, and can’t use my addon store instead of the mozilla one, isn’t that contrary to the mofo principles?

    1. Jorge Villalobos wrote on

      You won’t be required to list or host your add-ons on AMO. Your add-ons will need to be submitted to AMO for signing, but that’s all. We won’t support other signing keys, however.

  48. anonymous wrote on

    I understand your reasoning for wanting to do this. But I want to let you know that this is extremely maddening to me.

    I use a particular addon, but I don’t like certain aspects of how it works. I manually patch that addon myself after each update. You are now telling me that a program I run on my own hardware is not allowed to run code that I write. I have to ask permission from someone else to run code that I write. I refuse to ask permission from anyone to run code that I write. Even if I was okay with that, I would refuse to wait weeks and weeks to get that permission. And I’m not even sure I’d get that permission, because the code I submit would be substantially the same as some existing extension only with a few tweaks, not even with the name or unique identifier changed.

    Your workarounds are unacceptable. Run unstable alpha-grade code as my daily driver? Are you fucking kidding me? Remember, this isn’t for testing. This is the browser I use every day, for all my normal tasks.

    You say there will be unbranded builds that include the ability to run unsigned extensions with the stable channel. Where? Do they exist today? Will they be supported by Mozilla? Will they be as stable as the branded release channel? Will I be able to go to the Mozilla FTP site and get an unbranded build of any release like I can today? I didn’t think so. “Use some rando’s homemade builds” is not an acceptable answer.

    Again, I understand your stated logic for doing this, but you must know that this is not a plan that comes without creating significant anger and resentment for your users. It is all I can do to not want to throw something at the wall right now.

    1. Jorge Villalobos wrote on

      > You say there will be unbranded builds that include the ability to run unsigned extensions with the stable channel. Where?

      We will link to them from the Developer Hub on AMO, and probably from MDN as well. We haven’t determined where they will be hosted.

      > Do they exist today?

      No.

      > Will they be supported by Mozilla?

      Yes.

      > Will they be as stable as the branded release channel?

      Yes.

      > Will I be able to go to the Mozilla FTP site and get an unbranded build of any release like I can today?

      I’m not familiar enough with our Release Engineering process to know the answer for this, but I think it’s a good idea to host these builds on FTP. I’ll definitely ask for that.

  49. Richard Neill wrote on

    I think this is a good idea *provided* that Mozilla takes great care to act in an unbiased way and moderates only for security. After all, most of us Linux users implicitly trust our distro to act as gatekeepers with signed packages, and curation of what is allowed in the repository.

    But, with great power comes great responsiblity. So, for example, Mozilla must not block an extension that bypasses censorship (even if warned that it is illegal to do so). Nor can Mozilla bypass extensions that allow, for example, access to grey-markets such as Silk Road, or that do ad-blocking, DRM circumvention (even if it’s Firefox’s own DRM being circumvented), etc. On the other hand, we do all know pretty well what constitutes “Malware” and if Fx blocks this on behalf of the vulnerable user, I say well done to you.

    As for user-freedom – as long as there is a compile-time option to disable this feature, I think I’m happy with it. You just have to take very great care with this extra power.

    1. Anonymous wrote on

      > After all, most of us Linux users implicitly trust our distro to act as gatekeepers with signed packages, and curation of what is allowed in the repository.

      You do know that you can easily install packages from 3rd parties without any gatekeeper. “sudo dpkg –install untrusted.deb”.

      That’s all it takes. No switching to unbranded versions, no waiting for reviews or anything like that.

  50. Robert wrote on

    What about Linux distributions that use native packaging (RPM, deb) to distribute extensions? Some people think that distributing them that way is not necessary, but for networks that want global installation of extensions for all users and be able to disable installation from AMO and public sites via preferences is needed.

    Requesting that Linux distributions build processes need to upload binaries to AMO will not be accepted because those builds should be repeatable by any user using the source RPM for example. The future describe way for internal networks probably could help, but if the restriction about not being distributed outside the network is enforced, it will not fly for distribution built RPMs or debs.

    Please take the into account this case. XPI per user is an awful way to distribute approved extensions on corporate intranets, and not being able to use distribution built packages for extensions will only add more work for downstream users of those distributions

More comments:1 2 3