1. Tom Schuster wrote on February 11, 2015 at 4:36 pm:

   Why don’t you give developers a singing certificate that they can use to sign their add-on, but can be revoked? I guess the whole point here is to make it easy to blacklist add-ons, or do hope the review process is going effectively catch bad addons?

   This change only prevents the user from installing malicious add-ons themself. I predict that it’s not actually going to prevent sideloading. Malicious actors are just going to start replacing the Firefox binary or similar.

   1. Jorge Villalobos wrote on February 12, 2015 at 7:03 am :

      > Why don’t you give developers a singing certificate that they can use to sign their add-on, but can be revoked?

      Because of the high risk of lost/stolen keys, or malicious developers obtaining a key “legitimately” and signing tons of add-ons. This system gives us much better control over which add-ons are signed, and we have access to the files being signed.

      > I guess the whole point here is to make it easy to blacklist add-ons, or do hope the review process is going effectively catch bad addons?

      It’ll be easier to block add-ons, yes, and we expect the automated process to catch sufficient malicious add-ons to make a difference.

      > Malicious actors are just going to start replacing the Firefox binary or similar.

      That is possible, but I don’t expect the majority of malware developers to go through such trouble. They will choose the path of least resistance to accomplish their goals, which is why they attack Firefox through randomized extensions, since it’s trivial to do.

      1. Daniel Miranda wrote on February 12, 2015 at 7:51 am:

         The PKI system works for handling keys that are used to secure people’s lives and money, but cannot be trusted to install addons? Will you be blocking custom HTTPS certificates too when you deem them too dangerous? What happens when a dedicated attacker goes afters Mozilla’s certificate? Will you accept revoking it and breaking every single add-on in existence? Please stop with the hubris and LISTEN to all the arguments made by your users. The single-signer system makes no sense whatsoever. Even Secure Boot that is meant to hold off rootkits accepts custom keys because it would be a violation of consumer trust and even laws in many places. How can you disrespect your users in this fashion and act like it is fine?

      2. Tom Schuster wrote on February 12, 2015 at 8:18 am:

         One the one hand you fear that people will steal singing keys, but patching the Firefox binary is troublesome? Sorry this doesn’t make sense.

         1. Jorge Villalobos wrote on February 12, 2015 at 12:49 pm :

            You think it would be difficult for one of many developers to have their keys compromised? Why do you think it’s so unlikely?

            1. Tom Schuster wrote on February 17, 2015 at 4:33 am:

               It’s not unlikely, but it’s also not unlikely that somebody passes your review process. Thus you already need a way to revoke addons, it doesn’t seem like a stretch to instead have a mechanism to revoke keys.

            2. Jorge Villalobos wrote on February 17, 2015 at 7:42 am :

               There are a number of differences, though. We can easily spot on AMO if someone is trying to create dozens or hundreds of add-ons. We would have access to those files and determine if there are code patterns we can flag to prevent similar submissions in the future.

               We already have ways to revoke add-ons: the blocklist. One of the big problems is that the malware ecosystem has evolved to work around it, and we need some level of control over the production of add-ons and add-on IDs so that it can be effective again.

      3. michaelw wrote on February 13, 2015 at 8:12 pm:

         First of all, it’s outrageous that there will be any preferences or command line options to disable this.
         Recommendations, using a nightly or developer release in order to be able to disable this are pointless. As a experienced user I want to use the stable version but with option to install addons, where I decide whether It’s safe or not, after I reviewed the code. And maybe I don’t want ask Mozilla, whether if this addon is good for me. My system, my decision, my responsibility.
         Beside this personal freedom of choice, there is another point of this so called improvement which raise my concerns.

         > Because of the high risk of lost/stolen keys, or malicious developers obtaining a key “legitimately” and signing tons of add-ons. This system gives us much better control over which add-ons are signed, and we have access to the files being signed.

         Therefore Mozilla will be the only authority to sign the addons. Probably you are right, there could be a potential security risk through lost or stolen keys, if third parties would also be able to sign addons .
         Obviously Mozilla don’t trust anyone. Not their advanced users nor any other organisation.

         While looking back the recent years, you’ll remember several big security breaches like Apple Developer Website, Kernel.org, RSA, Adobe, Sony, etc. …

         And nobody would ever attack Mozilla?

         Oh, wait.
         It’s not even necessary.
         Why?
         They do backups: https://blog.mozilla.org/security/2014/08/01/mdn-database-disclosure/

         TL;DR
         Good intension, bad implementation

2. Anon wrote on February 11, 2015 at 4:37 pm:

   How would you react if microsoft decides that there are to many malicous softwares out there and change windows so you can only run programs that were approved by them? And yes, I’m making the comparision from browser to OS, because the browsers are the operating systems of the www.

   1. Jorge Villalobos wrote on February 12, 2015 at 7:05 am :

      Apple already does this to some extent on OS X, and Firefox is still supported on that OS. If Microsoft did the same, I don’t expect Mozilla to stop supporting Windows in protest.

      1. Daniel Miranda wrote on February 12, 2015 at 7:52 am:

         Apparently you don’t hold Mozilla’s values at your heart them. Maybe you should not be on your position in this case.

      2. Denis Kasak wrote on February 12, 2015 at 8:47 am:

         Perhaps not, but I suspect many users will stop supporting and using Firefox in protest of this shark jumping.

      3. mx wrote on February 12, 2015 at 9:10 pm:

         Apple’s process on OS X is very different as you are almost certainly aware. Gatekeeper can be turned off entirely in System Preferences and/or bypassed on a one-time basis by right clicking. Furthermore, Apple issues signing keys to registered developers, but does not sign the actual binaries. This leaves developers free to sign and release binaries as they see fit, while giving Apple the ability to revoke an individual developer’s signing authority if abused. This is completely different from the pre-approval model you propose here where each release of an extension cannot be signed without Mozilla’s individual approval.

3. mvario wrote on February 11, 2015 at 5:33 pm:

   My concern, the same that I see others have, is the lack of any override. I use some old addons, and I occasionally use some pre-release addons from the developers. I don’t want to not be able to do this.

   I suppose I will be forced to use a developer version, but since I am on Linux (an Ubuntu derivative) and currently get Firefox via the repository I’ll have to hope for a PPA of the developer build.

   I do wish/request that some sort of override (even if a bit too difficult for casuals) would remain available for more advance users.

4. Mark A. Ziesemer wrote on February 11, 2015 at 6:22 pm :

   > 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.

   I look forward to additional details regarding this. I’ve created a Firefox extension that utilizes Firefox to display an unattended “NOC” monitoring dashboard for my organization. Needing to send each build of this off for external signing would not be feasible. Complete control exists over the PCs and Firefox installations hosting the dashboards – so in lieu of having an “about:config” option that could be used to bypass the signing requirement here, whatever provision is being promised here had please better cover this use case. Otherwise, we’ll need to consider forgoing any Firefox upgrades to prevent an issue here – which obviously would not be ideal.

5. DegenarateSpyInfestation wrote on February 11, 2015 at 6:44 pm:

   Mozilla hairbrained changes, turning the interface into chrome shit along with stupid oversized buttons in a fucking menu on the wrong side of the screen.

   Dialog window for options, going into a fucking tab (maxthon2 did it years ago before shitting chrome), oversized interface with fuck all options really, that was better suited in a smaller popup dialog. on the Desktop.

   Users are increasingly having to find addons just to add back functionality that some moztard removed out of the base desktop browser.

   You break addons every release and developers just abandon them which seems to be an ongoing tradition, while adding fuck all useful features to replace them. Since FF3.5 nothing about the interface or features of the browser have been of an improvement on stupid shit changes, addons are the only fucking thing Firefox has, and since 3.5 it has been going DOWN FUCKING HILL.

   Mozilla you don’t give a flying shit about users privacy or security. This is more about control, of the stupid kind.

6. Adam Novak wrote on February 11, 2015 at 8:32 pm:

   Will AMO always be the only CA for signing? Or have you considered authorizing a few different editors to curate the catalog? I’d be more comfortable if Mozilla didn’t have unilateral Apple-app-store-like veto power, and it can’t be that hard to find say 3 organizations that can agree on what malware add-ons look like.

   1. Jorge Villalobos wrote on February 12, 2015 at 7:13 am :

      We won’t be giving away signing rights to arbitrary parties, certainly. I’m not clear about your suggestion of a few other editors, though. Do you mean that someone like say, the EFF, should be able to sign add-ons independently?

7. CH wrote on February 11, 2015 at 8:57 pm:

   Thanks for this; you’ve really raised the bar and made life better for non-technical people everywhere.

   The bad actors are going to have to get sneakier. Specifically, they’re going to have to make their addons so that they don’t do anything bad until weeks have passed. The addons will have to check the client’s ip address, and be perfectly ordinary when they are in the testing facility, saving their bad behaviour for certain countries or netblocks. If they’re able to download ads from a server, the server might give the signal, or send malicious code inside an image file that can be decoded by the addon. The only hard part is writing the addon’s code such that it passes inspection when it is submitted.

   So, when you write your addon-scanning program, look for unreachable code, incomprehensible or encrypted code, ‘if date>xxx’ conditions, and the ability to download code after the addon has been approved. It’s the halting problem and the underhanded coding competition rolled into one!

   1. Axel Grude wrote on February 13, 2015 at 4:14 am :

      there is not simply an automated “add-on scanning program”; EVERY LINE of any addon going online has to be reviewed by an editor. That’s why we do not like people submitting modified version of big libraries such as jQuery. It slows down the Review process but reviewing EVERYTHING is ultimately the safest method.

8. haha wrote on February 11, 2015 at 9:28 pm:

   “The Mozilla Manifesto

   These are the principles that guide our mission to promote openness, innovation & opportunity on the Web.

   Our 10 Principles

   5. Individuals must have the ability to shape the Internet and their own experiences on it.”

   Okay then.

   1. Daniel Miranda wrote on February 12, 2015 at 7:53 am:

      It’s just a facade. Mozilla is dead now.

9. Another User wrote on February 11, 2015 at 9:36 pm:

   I am clearly not the target audience for whatever direction Firefox is heading. Incidentally, your new audience installs Chrome because its what Google told them to. Sell outs.

   1. Carlos wrote on February 12, 2015 at 11:49 am:

      Apparently, me neither… I’m disappointed.

10. Josef wrote on February 11, 2015 at 9:57 pm:

    Stop whining, if you need hacked extensions just use unbranded. If you’re in a corporate environment and you have an internal extension in use, there will be an enterprise option.

    Jorge, will it be possible to whitelist extensions but otherwise use signing in unbranded (or even use our own keys) or is the signing an all or nothing thing between the two versions?

    1. Jorge Villalobos wrote on February 12, 2015 at 7:17 am :

       The current plan is that the unbranded and pre-release versions will have a switch to deactivate the signing check. So, you can flip the switch whenever you need to install an unsigned extension. I don’t think we will be implementing any whitelists or support for additional keys.

       1. Daniel Miranda wrote on February 12, 2015 at 7:55 am:

          Why do you prefer to lock out every user and give no alternative for fine-grained security? What happens if you Mozilla gets it’s certificate stolen?

          1. Rintoul wrote on February 17, 2015 at 10:31 am :

             Please quit using “it’s” when it should be “its”. It’s driving me nuts.

11. Anon wrote on February 11, 2015 at 10:18 pm:

    If the reasoning behind not having a config option is 3rd party non-web malicious installers that have file permissions to change Firefox settings then there is no point about discussing security. You can’t protect the user on a compromised system. Enforce signature check for web based malicious threats but have the config option for unwilling users. 3rd party non-web malicious installers have many possibilites to infect the system or browser and Mozilla can’t play the part of an antivirus company.

    1. Jorge Villalobos wrote on February 12, 2015 at 7:27 am :

       There’s a difference between having access to the profile folder, either from an application or add-on, than having access to privileged files like the Firefox application installer. We’re aiming to protect against the more prevalent and “lighter” form of malware. I think we can agree that having a malicious application run with admin permissions is essentially game over and we can’t effectively protect users against it.

       1. Anon wrote on February 12, 2015 at 12:27 pm:

          In that case having the said config option in a priviledged file will solve the problem for everyone.

       2. tastic wrote on February 12, 2015 at 8:06 pm:

          “I think we can agree that having a malicious application run with admin permissions is essentially game over and we can’t effectively protect users against it.”

          Mozilla Maintenance Service: although not “malicious” it can, and does, break things… and we (admins, IT support staffers) cannot effectively protect users against it. Introduction of that was “game over” ~~ looking forward, good luck protecting users among the remaining (and noticeably dwindling) Mozilla userbase.

       3. Anonymous wrote on February 13, 2015 at 3:14 am:

          Having malicious code running with the user’s permission means game-over anyway, they could just exfiltrate about any data owned by the user. Changing the homepage or injecting ads seems insignificant in comparison.

    2. catdog2 wrote on February 16, 2015 at 7:29 am:

       There are so many ways for malware to manipulate the users experience, especially when it runs with full privileges. You can’t protect the user if he is willingly giving this rights to such software. Sure especially on Windows much could be done to protect the user from unwillingly doing so but this is the Job of the OS, there is very little an application like a browser can do about such things happening outside of its scope on a higher level.

       > Furthermore, malicious developers have devised ways to make their extensions harder to discover and harder to blocklist, making our jobs more difficult.

       And this will continue, they will use other tricks to get their ads, etc. inside the Browser, surely even harder to detect and to get rid of. Maybe some snakeoil “security software” (the ones which install SSL certificates to crack open your https traffic, you know) may detect some of it but they also could detect the ongoing malicious extension sideloading by installers if they wanted.

       > One important improvement that signing brings about is that the extension install experience will be renewed and improved.

       If i as a user can’t install some extension even if i clearly state that i want to do this i would consider this as the worst install experience imaginable. There must always be a (not too complicated) opt out of such “we protect you from yourself” things, especially if you are an organization which states something like “Individuals must have the ability to shape the Internet and their own experiences on it.” as a core principle.

12. oiaohm wrote on February 11, 2015 at 10:22 pm:

    Jorge Villalobos I hope the 3 option is personally signed using own internal certificates and the means to have more than 1 certificate for certified applications from checked against a predtermined source.

    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.

    Applications for internal network usage might have more than 1 developer group the reason for the more than 1 signing certificates possibly more than 1 CA..

    Having to submit to AMO to test is going to be a no go for a lot of legal departments for extentions that did not include proper licensing declaration in the first place. Is part of the signing going to be confirmation that extentions have properly delcared licenses and extentions found without properly defined licenses will find signing pulled as required so forced to internal network key only.

    Please also remember there is a catch that some extention features may be legal in countries where for Mozilla its not legal. Yes different countries different rules on what forms of copyprotection can be bipassed for example.

    Is Mozilla going to release tools that can be intergrated into internal build servers and development tools to test for known bad? Why this will reduce failure rate on Mozilla servers.

    Yes Mozilla has a double responsablity. 1 to protect end users. 2 not to make it impossible to end users to source applications from other locations like company internal or other storage locations. Of course I really do agree with think twice before adding a public key an applications.

    Basically the sooner you document the internal network solution and how it can be used the sooner the worry might be able to be reduced if the internal network option is in fact open to everyone without costs. The internal network solution could be what “ANDY wrote on February 10, 2015 at 2:51 pm” and others require.

    Jorge Villalobos
    “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.”

    Jorge if something is not licensed correctly the face the signing by AMO will be evidence that the extention was provide to a third party. There are a lot of copyright exceptions as long as you don’t send something of questionable license state to a third party. The fact you are not hosting make absolutely no legal difference the problem is you are gluing on evidence of guilt so making it not workable.

    Yet all these case are most likely handled if the internal only signing works. Sooner you can do a post on how internal signing will work the better.

13. Rory O’Kane wrote on February 11, 2015 at 11:07 pm :

    This blog post could be improved by giving actual statistics about the prevalence of malicious add-on installs that you are trying to prevent. I think developers who read this would feel better about this new hassle of signing if they knew that (to make up some numbers) 10% of all “add-on ignorant” Firefox users (users who did not install any non-blacklisted add-ons), equalling 20,000 users, have a malicious add-on installed.

    Without knowing how bad the problem that this solves is, we developers can’t judge whether this solution is worth the inconvenience.

    1. Daniel Miranda wrote on February 12, 2015 at 7:57 am:

       Either way the chosen solution is bad. There are multiple ways to protect the signing setting or trust store from malware, like through the master password or the system credential store. But those that claim themselves defenders of the open web cannot consider any other solution, or even respond to them, that does not involve them holding all the keys. Even though the PKI system is used to secure HTTPS, and therefore all their users data anyway.

14. Chris wrote on February 11, 2015 at 11:46 pm:

    Bye bye “Chromefox”. I did not like the “new” copycat look but I cannot abide taking freedoms from the community that gave you the success you have. You have lost an advocate and supporter. I will donate my valuable resources elsewhere and suggest people not use your products because you are now no better than anyone else who wants to control things.

    The moment you put this mechanism in place it becomes another potential weapon to be used against the people. Give and inch and they take a mile.

15. Adrien wrote on February 12, 2015 at 12:31 am:

    This is sad. I’m using some really old Firefox extension, that are working well, but there is no maintainer anymore. This is an extension that modify the behavior of one site, but I use it everyday. No one would be able to submit it to the Mozilla signing process. I don’t want to need to install a instable version of Firefox, just to use it as before.

    Again, please consider a secure way to disable this check, like (as said before), a root write-only file.

    1. Anon wrote on February 12, 2015 at 10:02 am:

       I very much agree with this. There are lots of old non AMO extensions around and without the option of turning signing off the majority of Firefox users will never be able to test them or possibly improve them. This also will create a negative effect on the extension ecosystem, enforced signing is a high entry barrier for most of the aspiring amateur extension developers or curious users, quickly creating a test extension and immediately testing it on the daily browser was common. The curiosity of these type of users will die quickly when they learn they have to go through a signing process or download another browser.

       Another negative effect is on the nightly beta testers of extensions, many of them use a stable version of Firefox and now they woud be forced to change their main browser if extension developer doesn’t want to sign beta extensions. Most of them won’t be willing or able to change their browser to an unstable or unbranded Firefox and this will be a downside for both developers and users.

16. Andrew McGlashan wrote on February 12, 2015 at 1:19 am:

    I’m an IT guy, but I am really starting to get pissed at so many things that are going on.

    You can lock things down for people whom don’t know what they are doing, but you must give those that are informed a chance to do things that Mozilla doesn’t approve (for whatever reason).

    To name a few things that are currently annoying me, only the first one is not relevant to Mozilla:

    [1] systemd — I DO NOT want Lennart Linux

    [2] I have UPS equipment that is using SSLV3, therefore I cannot use current Firefox to manage things, the equipment is safe to administer, even though there are no updates available to use TLS1.2

    [3] Firefox add-on signing, without me being able to choose whether or not I want the add-on that isn’t signed by Mozilla, that’s a disaster to me — there MUST be an option to override, even if a warning has to be loud and clear. For some reason, plugin check isn’t working right now for my browser. And why the hell do you need google-analytics for plugin checks to work?

    [4] Plugin checks on some versions of OS don’t work properly, they say an update is available for Adobe Reader when one is NOT available for that OS.

    [5] Thunderbird add-ons, I’m not even sure all the plugins I use can be downloaded again.

    Oh and Java…. (just another vulnerability announcement).
    – Oracle create an update, but won’t let anyone have it until their CPU date arrives
    And they will stop availability of java 7 — if you don’t have it already, you won’t be able to download it from Oracle.
    NB: I only use Java [and it must be Java 7 today] in very restricted circumstances and it IS required for iLO works on servers locally.

    When updates of Firefox breaks my add-ons, it isn’t a good day, that hasn’t happened recently, but it’s sure as hell going to happen if you enforce strict signing requirements.

17. Paolo Inaudi wrote on February 12, 2015 at 1:49 am:

    I agree with most other users saying that I feel this against FOSS principles, and FOSS principles are the main reason I choose Firefox as my main browser on all platforms. As you said, if the attacker has root privileges on the machine, then everything is broken anyway, so I don’t see why there can’t be a setting in a global configuration file where you can add something like “User X [on profile Y] is allowed to run {extension Z|all unsigned extension} {with|without} a big fat warning”. And also allow a user to sideload his own certificate.
    I don’t want either of the two. I want both options. The former allows freedom in installing third party extensions not approved. The latter gives me freedom of installing my own extension, without approval of Mozilla.

    You will reply you can submit {the same third party extension with modified id|your own extension} to AMO for approval for redistributing. This is not the same thing. My executable still has to get out of my private network. Might need to be checked from a Mozilla employee. I can trust the Mozilla Foundation (or are you a corporation now? I missed the point of that), but I may not want to trust every single employee in it.

    To end my argument, as also someone else has pointed out, using development version/the unbranded version is not a valid alternative. Development version is unstable, and the unbranded version has the entire signing system, which I might want to use, completely disabled. Moreover, it won’t be available in linux distributions repositories.

    Of course malicious extensions will offer instructions on how to run them. But there is no point in trying to protect people who wants really badly to be compromised.

    I hope those arguments will be taken into consideration. I also posted this on the mailing list, but I will repost here for everyone to see (mainly because I don’t know if it’ll be approved by moderators since I’m not a member).

18. tomitu wrote on February 12, 2015 at 2:52 am:

    This will be pointless – there are many new malware that are installing itself as a proxy in system, even for https connections. And this way they are injecting ads, scripts, etc.

19. Elessar wrote on February 12, 2015 at 2:52 am :

    Mozilla moving to enforce mandatory applicative DRM, seriously? That sounds quite bad…

20. Feng wrote on February 12, 2015 at 4:30 am:

    Are plugins also required to be signed? If they are, can the owner sign?

    1. Jorge Villalobos wrote on February 12, 2015 at 7:18 am :

       This doesn’t apply to plugins, only extensions.

21. Jean wrote on February 12, 2015 at 5:54 am:

    Don’t close firefox please.

    Let me use what I want. Let me uncheck a “check extension” button if you want, and don’t force me extension choice.

    1. Jorge Villalobos wrote on February 12, 2015 at 7:19 am :

       You’ll still be able to do what you want if you use one of the unbranded builds or the pre-release versions.

       1. Mikhoul wrote on February 12, 2015 at 8:06 am:

          It’s FALSE Jorge I will not be able to modify an old broken abandoned add-on to work ONLY on my own PRIVATE computer on the fly or use a beta add-on to with a quick fix from a developper.

          Sadly Mozilla close Firefox to be a clone of Chrome, As power user I need to be able to control my working environment and do some things that casual users don’t do.

          In another word: I think Mozilla don’t want Power Users no more,… But you will lost a lot of evangelist like me if you don’t put a disable mechanism for power users. I will move over 150 users to another browsing solution with that change,

          Enough is enough. 🙁

          1. Jorge Villalobos wrote on February 12, 2015 at 12:48 pm :

             If you don’t want to submit the add-on for signing, you can always use Nightly, Developer Edition, or the unbranded builds.

             1. Andrew McGlashan wrote on February 13, 2015 at 8:07 am:

                That is not an acceptable solution for managed end user machines. 🙁

22. Samuel J. Sanchez wrote on February 12, 2015 at 6:26 am:

    “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.”

    Extension signing would do NOTHING to prevent this. Your stated reason for not allowing an about:config setting to disable the “feature” is that “malicious add-ons and applications can easily manipulate those settings” … that means malicious applications can easily manipulate the homepage and search settings, too! In other words, the first two use cases you listed are moot.

    Also, unless you plan to also require signing of all userscripts for extensions like Greasemonkey, a malicious application could simply install the (signed) Greasemonkey extension and then enable their own malicious userscript, allowing them to inject advertisements into Web pages and malicious scripts into social media sites, your second two use cases.

    None of your use cases have been addressed. This is BS.

    I have non-public personal extensions that I want to continue using. I don’t want to have to provide my code to Mozilla just so that I can continue using it.

    1. Jorge Villalobos wrote on February 12, 2015 at 7:21 am :

       It’s certainly true that we can’t block all kinds of malicious behavior, but we believe this will help curb a significant part of it.

       1. Samuel J. Sanchez wrote on February 12, 2015 at 7:42 am:

          Why won’t you include an about:config switch when you acknowledge that your rationale for not including the switch — that malicious applications can work around a switch — is just as true with respect to malicious applications working around the restriction itself in the use cases you’ve outlined?

23. Derry Shribman wrote on February 12, 2015 at 6:49 am :

    We’re glad to see Mozilla moving to a faster review process and not allowing malicious extensions to exist within the eco-system, similar to how Google has done with Chrome.

    Hola is the 8th most popular extension on Google’s Chrome (5.2m active users), allowing users to overcome blockages and enjoy complete freedom of information. On Firefox, users have had to install Hola directly from our web site (~8m installs to date) since the existing review process rejected extensions that dynamically modified the proxy settings. As a robust VPN product, we’ve had to do that in order to be agile (and this is what we do with Chrome as well).

    The Hola extension is completely ad free (… and does not inject any ads), does not change the homepage nor change or capture any search assets. It does however modify the proxy settings dynamically (otherwise the users will be easily blocked) with full user consent. Will the new review process allow Hola to be downloaded from the Firefox extension marketplace?

    If not, would we be able to sign the extension and still host it on our web site? (assuming that its still not malicious, doesn’t inject ads, etc?)

    We would love to return to the Firefox marketplace and not have to encourage our FF users to move to Chrome.

    1. Jorge Villalobos wrote on February 12, 2015 at 7:23 am :

       While we can’t host it on AMO, it should be okay for signing.

       1. Daniel Miranda wrote on February 12, 2015 at 8:06 am:

          Until some external entity decides for you that it is not and forces you to revoke the signature. Did you completely ignore this possibility? Is Mozilla above abusive governments and laws? Is it willing to subject the whole world to US law just to satisfy it’s desired for control?

          1. Jorge Villalobos wrote on February 12, 2015 at 12:47 pm :

             Those external forces could also theoretically force us to blocklist any add-on they want. What would be the difference?

             1. Viktor wrote on February 12, 2015 at 2:48 pm:

                Because before you implement this, there is no way for you to block ANY addon.

             2. Jorge Villalobos wrote on February 12, 2015 at 3:53 pm :

                Replying here because of comment nesting.

                Yes, we do have a way to block any add-on. It’s the add-ons blocklist, and we block malicious add-ons regularly. One reason we need signing is that certain malicious developers have been making it much more difficult for us to block them.

                In the hypothetical case where a government wants us to block some add-on, we’re probably talking about a non-malicious one, which would be fairly easy to block, and always has been.

             3. Daniel Miranda wrote on February 12, 2015 at 7:36 pm:

                I can disable the blocklist with an about:config setting. That’s the difference. It’s impossible to get through your head that an unbypassable restriction is not acceptable. Just because you are not technically competent or creative enough to formulate a setting that cannot be faked by addons does not excuse you from respecting the values you claim to hold.

             4. Daniel Miranda wrote on February 12, 2015 at 7:36 pm:

                Faked at installation time*

       2. Project LibX wrote on February 12, 2015 at 9:18 am :

          We are in the same boat with LibX. We made an attempt many years ago to get on AMO, but they fundamentally won’t allow what we built an infrastructure to do – loading userscript-like code from a remote source post plug-in installation.

          Google Chrome, needless to say, has no problem with that.

24. Mikhoul wrote on February 12, 2015 at 7:53 am:

    Completely STUPID decision like most decision since 2 years ago… 🙁

    I have lot of old add-ons (abandoned that I patch myself) that are the reason why I stay with Firefox, so no more reason to stay with Firefox since they remove all customization “à la Chrome”. 🙁

    At least if you have a switch in the about:config to disable it. But you want to control everything and the user have no control on anything —-> Power to the User not to Mozilla.

    Sad Day !!!

    Enough is Enough: I will prepare to change my whole set-up and working flow to use another browser and migrate all my users (over 150) to another browser.

25. Jaroslav Škarvada wrote on February 12, 2015 at 8:22 am:

    Really sad to see Mozilla going this way, basically copying Apple and Google and their closed stores.

    Centralized signing, indexing, approval and dictating users what they can install and use on their machines (without possibility to opt-out) is always bad and effectively killing FOSS nature of the project, no matter how you try to justify it.

    I have been with Mozilla SW since the beginning, but it seems it’s time to move.

26. Firwen wrote on February 12, 2015 at 8:31 am:

    Ban is too much.

    a ban of the unsigned application is simply too much and this is not usual for Mozilla to be so absolute in their choice.
    Even Android allows to install unsigned software. Are mozilla trying to be more close minded than Google ?

    I can perfectly understand that a warning “This is unsigned, and not safe, do you really want to trust this ?” is not acceptable as a long term solution due to the basic user behavior to accept everything by default.

    Then, a simple boolean to configure in “about:config”, accessible only to advanced user that know what they are doing would do the job.

    And ‘Gran’Ma’ would simply forget the idea to install the toxic sUpErToolBAR that X.com ask her to install.

    Please at least, keep the option.

27. Vadim wrote on February 12, 2015 at 8:44 am:

    For advanced users, please leave the possibility to install unsigned addons. By default, this option is turned off, but to be able to turn it on through about:config.
    If the goal really is not to limit freedom.

    1. Jorge Villalobos wrote on February 12, 2015 at 12:50 pm :

       Please read the post for explanations on how users can continue to use unsigned extensions. about:config is not an option because it’s too easy to modify.

28. heilage wrote on February 12, 2015 at 8:49 am:

    Sadly, these measures may lead to absence of some Firefox extensions at all.

    For example, we’ve built an extension for firefox and tried to submit to AMO, but it did not pass the requirements for reason that it uses some external API which is loaded as an external js script. Also it uses some libraries that are not whitelisted for usage in extensions – seems that Mozilla extension check has some kind of a whitelist of libraries and their checksums to automatically decline an extension if some suspicious libraries found. So patched libraries do not pass, and non-patched libraries do not work.

    We tried to talk to moderators but got nothing. As a workaround, we hosted an extension on our site, and about 30% of our audience installed it that way. New rules totally ruin this workaround and still give no way to pass the moderation, since we can not exclude that external APIs and patched libraries from the extension. What are we expected to do?

    1. Jorge Villalobos wrote on February 12, 2015 at 12:51 pm :

       Those issues shouldn’t block your add-on from being signed. We’re trying to prevent malware to be so widespread, not to extend AMO policy to all add-ons.

       1. Anonymous wrote on February 13, 2015 at 3:24 am:

          And how do you verify that an addon is not malicious without enforcing AMO policies, such as the rule against minified sources?

          1. Jorge Villalobos wrote on February 13, 2015 at 10:23 am :

             We will make some changes to our tools, and we will also need to be more flexible in some cases. For AMO, since we do manual review for all add-on, we definitely needed all sources, hence the rule for developers to submit their sources.

             1. Anonymous wrote on February 13, 2015 at 12:34 pm:

                That doesn’t really explain how you can “verify non-maliciousness” without also imposing rules on people. those kinds of rules that up until now have driven them to distribute XPIs externally.

                For example if the extension contains some proprietary, compiled native code libraries for various platforms. I don’t see how you gonna verify that.

                And if the review process is semi-automated, has lower standards and getting a new AMO account is not supposed to be onerous on developers that also means the bad guys can simply make an account, an addon that appears useful and benging on the surface and only unleashes its payload months later when they got tenthousands of installs.

                You can block them, but they’ll just make a new account and repeat the game.

                So either you DO impose AMO-like policies on this process, which means blocking legit addons that are possible right now. Or you have a so lax review process that it is possible for the bad guys to game it.

             2. Jorge Villalobos wrote on February 13, 2015 at 2:04 pm :

                It certainly won’t be impossible to game, and that’s not what we’re aiming for. Even in the scenario where you describe where a signed add-on becomes bad, we have much better oversight and capability to block it than we do now.

29. Some Name wrote on February 12, 2015 at 9:06 am:

    What if I create an add-on containing content that is illegal in the United States? How would potential users use it if signing was required?

    1. Jorge Villalobos wrote on February 12, 2015 at 12:53 pm :

       If the add-on is not malicious then it shouldn’t be a problem to have it signed. We don’t intend to host or distribute any of the non-AMO add-ons we sign.

       1. oiaohm wrote on February 12, 2015 at 11:44 pm:

          If the add-on is not malicious then it shouldn’t be a problem to have it signed. We don’t intend to host or distribute any of the non-AMO add-ons we sign.
          Jorge Villalobos DMCA intervention orders could in fact prevent you from siging. There is another big one. Patent infringement. If I am in a country where the patent does not apply and you are in a country where the Patent does apply you cannot legally touch it.

          Jorge Villalobos we need the internal network signing solution. The internal network signing solution should be able to deal with all these trouble making problems.

          Yes as a developer you just have a privite key pair set add your own key to the browser and for you everything is fine. Only when shipping to others is your keypair required.

          In cases of items that Mozilla cannot sign/host for some legal reason allowing room to add other CA groups could solve problem. Yes set up groups in countries where patents and dmca don’t apply to test/provide items Mozilla main legally cannot.

30. Aris wrote on February 12, 2015 at 9:54 am:

    The article isn’t clear about ‘pre’/’beta’ versions of add-ons. What happens to add-ons development channel? Will it be only accessible for users of Firefox Nighty and Developer Edition?

    Currently ”pre’/’beta’ versions of add-ons do not get reviewed, but are publicly visible for all users and are also distributed via autoupdate for those on add-ons development channel.

    1. Jorge Villalobos wrote on February 12, 2015 at 12:57 pm :

       They will probably be treated like non-AMO add-ons, so they would go through automated tests and might require additional review if they don’t pass.

       1. Aris wrote on February 12, 2015 at 3:20 pm:

          But isn’t bypassing a “full review” and testing new add-on features on a smaller audience the whole point of releasing “beta” versions of add-ons?
          Wondering how non-AMO add-ons would be treated in that case, if they are hosted on AMO (beta channel). 😉

31. Dan wrote on February 12, 2015 at 11:05 am:

    I dont believe its a good idea to restrict access to addons/extensions of others that dont have signatures from mozilla or of such. I dont believe its your job to solve human stupidity, just because some are installing adware/spyware onto there computer which in turn infects there browser. This is like a centralized way for addons to work compared to the older way where anyone was free to post there addon and get credited by reviewers stating its benefits and such.

    1. Dan wrote on February 12, 2015 at 11:11 am:

       Your only shooting yourself in the foot with this mozilla as well as the heavily regulated comment system on your website which doesnt allow offensive words or any form of “heavy” criticism to be posted. I will now not download any more products from you or recommend them to anyone else.

       1. Jorge Villalobos wrote on February 12, 2015 at 12:58 pm :

          If we didn’t allow heavy criticism on this blog, we would have about 20 comments instead of 200+.

          1. Dan wrote on February 12, 2015 at 1:16 pm:

             And yet one of the comments i made was removed from your site, so much for you “allow(ing) heavy criticism”.

             1. Jorge Villalobos wrote on February 12, 2015 at 1:49 pm :

                Are you sure about that? I see 3 comments from you, all published. I have only moderated 2 comments that were personal attacks and deleted one after (incorrectly) publishing that had very offensive language, none of those from you.

             2. Jorge Villalobos wrote on February 12, 2015 at 2:36 pm :

                (I deleted a reply to my comment above)

                Ah, so the offensive one was yours. Well, yeah, we don’t allow that sort of language around here. And that’s not how “freedom of speech” works.

             3. Dan wrote on February 12, 2015 at 3:00 pm:

                it kind of does work like that, your just getting offended by it. However I can at least agree that commenting is at least much more easier than any other site which would have you make an account and remember it forever; Whilst here i can just get one of my email, make up any name(as long is it doesnt offend you) and post.

             4. Noitidart wrote on February 13, 2015 at 3:20 am :

                Dang Dan. Freedom of speech doesn’t mean go chew out your boss. You do that you get fired. Everywhere has rules man. You make another account and post the same junk it will also get deleted.

             5. Dan wrote on February 13, 2015 at 10:21 am:

                I get the point Noitidart and will not be making anymore comments like that of my other account, although I still feel as if for what it being stated about addons is wrong. It shouldnt be anyone stating what addons or extension can be installed on the persons browser it should be there choice, regardless of how many people install adware/malware by mistake.

       2. Aris wrote on February 12, 2015 at 3:59 pm:

          The main problem with bad / 1-star / heavy criticized comments is, that 99,9% of them are wrong or are posted out of anger without thinking, because of misunderstanding what the add-on is for. It is not fair to discredit developers work because of that. Not liking an add-on is no valid reason to criticize it!
          Bad comments are only helpful and appropriate, if add-ons contain spyware and/or force unwanted advertisement on users, but such add-ons do not pass reviews, so this problem should be gone for a while.

          Devs spend their free time providing a “free product”, so if one can not respect that by giving positive feedback (or contact the devs through support channels in case of issues/bugs) , one should consider not to comment at all. Apples and Googles appstore comment systems made people believe they have to go hard on devs for every minor glitch / problem / misunderstanding by posting false bad reviews to draw attention to them.

          I’m glad we are offered a better way to deal with comments on AMO.

32. SPACED wrote on February 12, 2015 at 12:18 pm:

    Not much warning on this. With more notification, you could have saved some of us quite a bit of money that we invested in code signing certificates from CAs with roots baked into Firefox as currently required by signed extensions. I am from an organization that distributes signed extensions only to user’s in my organization for use not only on our networks but from internet systems. I hope that there continues to be a method for us to self sign and distribute our internal extensions. Otherwise, Firefox will cease to be of use to us and we will be forced to stop using it.

33. Priscilla wrote on February 12, 2015 at 12:38 pm:

    Yes mozilla go on force me like microshit,google,.i will stop using firefox its so simple

34. Alsee wrote on February 12, 2015 at 3:39 pm:

    There NEEDS be some way for the owner of the computer to disable / override / bypass this.
    Don’t force us start distributing a goddamn crack to patch the exe.

35. someone wrote on February 12, 2015 at 5:10 pm:

    I’m all for signed packages but
    >no way to bypass this even from commend line
    So just because I want to use an in development addon that I thrust (eg. µBlock on github) now I have to install an unstable version of FF or devs have to deal with signing in dev addons. I have to transfer profiles too of course. How about you add an option in preferences and then bring those red scary warnings explaining situation instead?

    I hope “unbranded” version will still check if addons are signed and my distro will add that into repo.

    1. someone wrote on February 12, 2015 at 5:13 pm:

       Also, I think warning and explaining situation may save more people and their troubles in the long run. Exposing this after enabling an option in preferences hides it enough, no?

    2. Jorge Villalobos wrote on February 13, 2015 at 9:20 am :

       That’s only assuming that the µBlock developers don’t want to sign their add-on. Also, they are planning on hosting their add-on on AMO.

36. Gerrit wrote on February 12, 2015 at 6:21 pm:

    I hope this measure puts and end to 3rd party applications installing addons without my permission, like AVG, Google Updater,

    Where can I download one of these “unbranded versions” you keep mentioning? I’m having trouble finding some links on google, all I find is discussion and instructions how to compile your own.

    Setting up a dev environment on Windows and compiling my own version seems too much trouble just so I can keep using my favorite addons. I consider myself a power user so I will accept the fact I will need to police my addons for any odd behaviour.

    1. Jorge Villalobos wrote on February 13, 2015 at 9:22 am :

       The unbranded versions don’t exist yet.

37. Michaela Merz wrote on February 12, 2015 at 7:04 pm :

    I am an international certified IT security professional. And I thought long and hard about that. And – while I believe that signature requirements have merit, Mozilla’s implementation leaves a lot to be desired.

    First and as previously posted, a single point of failure is way too easy to compromise – by legal and illegal action. Governments all over the world are coming down hard on services like tor. Mozilla might not be able to withstand legal pressure from the US government or even foreign governments – even Google compromised to keep the Chinese happy. And we’re not even talking about export restriction laws in regard to encryption.

    Second: Mozilla is exposing itself needlessly. If an extension slips through the cracks and gets signed – but is still able to do malicious things, Mozilla might and will get sued for damages. In order to avoid that, Mozilla will have to be very, very aggressive in regard to what kind of extensions are going to get their nod of approval. Don’t even think about asking me to contribute to you legal defense fund – you have been warned.

    Third: No security mechanism warrants the loss of liberties. Ever. You can educate, warn and suggest, but the moment you enforce, even with good intentions, you are no longer to be trusted.

    Conclusion: Make signature a requirement for the AMO. Your web side, your rules. Even Android allows side loading and a warning might be warranted. But if you continue with enforcing signature requirements for all extensions, you will shoot yourself in the food. And we all will lose.

    Michaela

38. Jay wrote on February 12, 2015 at 7:51 pm:

    -1. Sigh… at the very least make it so this restriction can be overridden.

39. Petr wrote on February 12, 2015 at 11:00 pm:

    Please, don’t do it!

    I’m developing some (very small and trivial) Firefox extensions JUST FOR MY OWN USE. I don’t have much time to invest in this.

    Using nighly builds is not acceptable for me. I just want to use the Firefox from my Linux distribution to be updated easily in case of security fixes.

    OTOH, the possibility to create small extensions for myself is crucial as it gives me the functionality I would otherwise not have.

    If you do this I will be forced to look for another browser. 🙁

    (Please, have at least an option in about:config, to switch the signature checking off. If you wish you can display a big red warning each time Firefox is started or something like this but PLEASE LET THE POSSIBILITY FOR ME AS END USER TO DEVELOP MY OWN EXTENSIONS!)

40. TheWrongThing wrote on February 12, 2015 at 11:50 pm:

    -1 for denying the option to allow install of unsigned extensions. This is a very bad move, Mozilla.

41. Jean wrote on February 13, 2015 at 12:43 am:

    Will you also restrict wich website I’m allow to visit for security reason ?

42. Pavel Cvrček wrote on February 13, 2015 at 12:58 am :

    My question is about review speed (for singing). Can we expect lower delays before publish than we have at this moment? I dont think developers want to wait for few days before approve.

    1. Jorge Villalobos wrote on February 13, 2015 at 9:26 am :

       The expectation is that the majority of submissions will get an immediate response since they’ll pass the automatic validation. Those that don’t can opt for a manucal review, which we aim to do within a day or so.

43. nope wrote on February 13, 2015 at 1:49 am:

    Face it Mozilla, the casual users you keep trying to win back are lost to Chrome and aren’t coming back. Why not spend your time making Firefox better for the people that actually use it, instead of making each release worse – and abandoning Mozilla’s principles – thinking you’ll gain market share?

44. Noitidart wrote on February 13, 2015 at 3:14 am :

    Can I drag my XPI local install unsigned? (i know you can for sure for nightly and dev and special unbranded as mentioned, but to release) i ask this because i rely on an addon GitHub Extension Installer: https://addons.mozilla.org/en-US/firefox/addon/github-extension-installer/

    1. Jorge Villalobos wrote on February 13, 2015 at 9:27 am :

       No, it wouldn’t be possible to install the unsigned add-on in any way.

45. j wrote on February 13, 2015 at 3:40 am:

    i’m just an ordinary computer user and have been for nearly 4 decades (1979)

    Mozilla’s Villalobos and the rules must be tightened. “Extensions that change the homepage and search settings without user consent have become very common…

    a bit like when my firefox was updated to an entirely different look – still don’t know how you managed to fool me into updating it (i have updates turned off) -and then no way to return my firefox back to its original look and feel (even Microsoft let you set vista up to look like an old version if you want)- i tried some addons but none of them made it exactly the same (and had i wanted a different browser i would of got one)
    after weeks of putting up with it i’ve just installed an old version which i will be keeping unless you release a new version with the same look and feel as the old one so all this signing nonsense will now pass me by – addons downloaded from Mozilla should already have been tested for malicious code should they not and that’s the only place i download them from. (and doesn’t that make much more sense – if you download from an unknown source whether it’s an add on or anything else your taking a risk and you know it – just because something is signed doesn’t make it any safer – if it did “fraud” wouldn’t exist would it.)

    from my point of view i don’t want any more big brothering – it’s bad enough that america and cloudflare are locking down the internet (with our help – free hosting aren’t we selling freedom cheaply and oh look free vpn’s paid for by grants from the good old usa -they are bound to be secure eh?) it’s all about the same thing – money protection, in the future nearly everything is going to be virtual goods and the rich need to retain there advantage over the poor (what’s the point of being loaded if the pauper down the street can get it for free) i see the UK government is going to make it so that male prisoners have to work (they already stopped them having the vote so they can do what they like with them, and with all the thousands of new laws they bring in sooner or later what you like to do will get you locked up) – that will make it a workhouse, next they will privatize the prison service so we will have private companies with huge forced labor (and if you think they will stick to making number plates and sacks your dreaming – they will be doing YOUR office job – this is the UK and they are always looking for a new way to cut labor charges -they just need to correctly “prepare public opinion”)
    oh yeah, i remember now – i’m a crackpot conspiracy theorist who doesn’t like change and treats with suspicion anything that’s forced on me, because i believe if it’s good for me i will CHOOSE it -not have it landed upon me in an update. look at that – that’s about five things i’ve posted on the internet ‘since the latter half of the 90’s

46. Noitidart wrote on February 13, 2015 at 3:51 am :

    I don’t see the big deal with signing people. It will make things safer. 99% of the internet is click and download. I just don’t want to see addons that fill your computer with spyware get signed just because the posted that filling your computer with spyware is what they do. I’m for this.

    1. Anonymous wrote on February 13, 2015 at 4:10 am:

       Because it is inevitable that the new scheme will forbid valid and currently possible (even if uncommon) use-cases.

       Hypothetical example:
       – I am a chinese developer providing extensions on his homepage
       – Chinese firewall blocks AMO (because it contains an addon injecting offensive content into chinese government pages for parody reasons)
       I suddenly have no way to distribute my addons anymore.

       And if they are forbidding things that are possible now and won’t be in the future that means they’re restricting the freedom of the affected users.

    2. LJean wrote on February 13, 2015 at 10:18 am:

       I look forward to this developing into something more user-aligned. I think it is an important first step, but if it is not well done people will learn to ignore it.

47. Jehan wrote on February 13, 2015 at 3:52 am :

    Hi,

    I love Firefox, but here, like many others, I think you should not make an unbreakable barrier to non-signed extension. You could make it a hard-to-pass like an option in about:config (which excludes most non computer-literate users: they will never go touch this and therefore this is the extreme protection for them), or a very red warnings which redirects to the AMO’s plugin web page with the piece of code flagged as potentially malevolent being displayed, highlighted and reviewable by users (as well as the rest, in some web UI allowing to review code), and then the user would have to write down in a text entry “I read the code and still decided to install it”. No common user will go that far (and thus you’ll have protected them).
    Don’t get me wrong: it is very good to check addons for malicious code and protect users as much as possible, but you should not have Firefox become a closed platform for this purpose. In the end, the users should always have the choice.

    The point is that the knowledgeable ones should be able to go over your recommendations. There are indeed a lot of cases where someone may want to use non-signed extensions and in the same time a release edition, because for actual daily use (and not a developer edition, which could be unstable, etc.). For instance I could want to make an extension for just me. Something practical *for me only* but not to be shared.
    Or there could be private extensions deployed at small scale (friends, or company employees, or something else…) but still for more than an internal network, but accessing the whole internet, and that you don’t want to publish either.
    What about people who have access to old addons (someone was in such a case in previous comments), they can still use them, even modify them for their private purpose, but they are not allowed to publish them themselves on AMO because they are not the rightful authors (and it had not been published earlier under a proper license, thus forbidding them to republish, only to use for instance) and unfortunately this author has disappeared (or simply won’t care and won’t maintain the old addon)?
    These are just examples from the top of my head. By searching more, I know we could find a dozen more actual cases where preventing install is bad (for a perfectly sane addon otherwise).

    And of course, the last unfortunate and bigger issue for this kind of “protection” is: what will happen next? I really heartly trust Mozilla. But we all know how the “protection”, first really thoughtful, can turn into censorship. We know the case from other platforms, in the mobile world in particular (iphone & co), and a lot of Mozilla people have been complaining about this. We know for instance that Mozilla’s software is not on iOS for the simple reason they don’t like other browsers there (well in December, you announced experimentation of a Firefox running webkit for iOS again, we’ll see how it goes). Of course Firefox is not malevolent, this is not the reason of problems with Apple. They just don’t want because they have the power and decided they don’t like you, just like they don’t like other perfectly sane applications which were not conforming to their standards: they don’t like the name — apparently this really happened! ; they don’t like the dev getting paid in-app without passing through Apple; they don’t like you mention other platforms; and they don’t like your contents, like sex or nudity-related, or religious, even when all is perfectly legal! And so many other reasons… Well you know all that, and I really don’t think, at least hope, that Mozilla is not going towards this. But blocking apps on your unique decision is definitely the first step.

    So I really hope you won’t go that way, and that you will step back from this stance. Just give a possibility for users to go over your recommendation and your checks (and make their own checks for instance), that’s all it takes. Don’t go in the “protect us against ourselves” direction, which is definitely not a good one and keep Firefox and all your software open platforms. 🙂
    Thanks!

48. Axel Grude wrote on February 13, 2015 at 4:23 am :

    A question – how is Fx going to handle beta releases? Do they have to be also signed ?

    And when developing Add-ons, is it sufficient to use a beta version for installation? How do we test our add-on prototype versions on a release version.

    I am currently preparing for shipping a new version of one of my Addons and I have built 975 xpi’s so far hope it doesn’t involve having to upload them in order to try them out. I usually use “pre” within my test builds, e.g. 3.15pre973.

    1. Jorge Villalobos wrote on February 13, 2015 at 11:32 am :

       Beta releases will also be signed and will probably go through the automated process like non-AMO add-ons. For add-on development we will provide unbranded versions of Release and Beta.

49. j. wrote on February 13, 2015 at 4:28 am:

    well,
    i did install the old version of firefox – i disabled the firefox update, i said no to all telemetry and updates, i installed a new clean windows on a new hdd.
    so now i run my forefox for the second time – guess what it’s updated itself to the new firefox, didn’t ask, didn’t warn – jusr happended

    now that’s malicious code if ever i saw it.
    i will try once more – if it happens again i may as well have chrome or ie – at least they ask “do you mind if i f**k up your old browser” before doing it.
    looks like i found out how you tricked me last time – it just happens in the background no matter what you disable.

    no way can this new firefox be good for end users or it wouldn’t of forced its way onto MY pc again.

    this goes with my previous comment about signing add ons as it speaks as to whether or not mozilla can be trusted with policing add ons – it’s a no from me.

50. Angly Cat wrote on February 13, 2015 at 6:38 am:

    I develop the site-specific add-on, which is automatically built on my machine, signed with modified McCoy (I’m talking about updateURL and updateKey fields) and uploaded to the github repo, so it updates automatically and my users always have the last version of the add-on. The process is automated and requires single cli command to do that all.

    Questions:
    1) will that fancy-shmancy update break add-on updating with updateURL and updateKey?
    2) will there be a way to sign with using just cli commands? Through oauth2 tokens or whatever.

    I don’t want to sign every development iteration of the add-on manually WITH MY FREAKING MOUSE clicking buttons.

    1. Jorge Villalobos wrote on February 13, 2015 at 11:35 am :

       We’re talking about implementing an API so it is easier for automated deployments. This has two caveats: (1) it’s not a blocker to implement this system, so it might not be available right from the start, and (2) there’s the possibility of the file not passing the automated checks and therefore not get signed, so it won’t be a completely reliable API.

       This shouldn’t break existing update mechanisms.

       1. Angly Cat wrote on February 13, 2015 at 11:32 pm:

          >it’s not a blocker to implement this system, so it might not be available right from the start
          So my deploying mechanism _will be_ broken for nobody knows how much time.
          >there’s the possibility of the file not passing the automated checks and therefore not get signed, so it won’t be a completely reliable API.
          That’s OK, actually, if it will work like this: I cURL my XPI and in response receive signed XPI with 200 OK or “There were problems” with 403 Forbidden, for example. Then my script will throw an error and I will have to do some actions manually. That’s the usual practice.

          Btw, is there any API to upload add-ons to AMO? If not, will there be such thing?

       2. Michael Kaply wrote on February 14, 2015 at 8:22 am :

          I’m assuming McCoy won’t work, though right? Because you can’t do the Mccoy signing because the extension has already been signed? And the AMO signing will break the McCoy signing.

          So extension updates will be required to be https?

          1. Angly Cat wrote on February 14, 2015 at 11:22 am:

             >I’m assuming McCoy won’t work, though right? Because you can’t do the Mccoy signing because the extension has already been signed? And the AMO signing will break the McCoy signing.
             That’s not right. McCoy do sign (after I put my ssl-key fingerprint as UpdateKey in install.rdf once) external update.rdf file (mostly the hash of XPI file and signature, which is calculated somehow very tricky using my ssl-key), so I think signing XPI with this fancy signing will not break this add-on updating system.
             >So extension updates will be required to be https?
             Why “will be”? It is required even now to be https. The only case you don’t need https is when you have fancy code signing certificate.

          2. Jorge Villalobos wrote on February 16, 2015 at 9:09 am :

             Do McCoy signatures interfere with regular add-on signatures? Is it not possible to have both?

             1. Michael Kaply wrote on February 17, 2015 at 6:16 am :

                > Do McCoy signatures interfere with regular add-on signatures? Is it not possible to have both?

                That’s a good question. I don’t know. McCoy modifies install.rdf, and my bet is that if the extension is already signed, the install.rdf will break the signing.

                But if you sign with McCoy first, the signing the XPI will break McCoy’s signature…

             2. Angly Cat wrote on February 18, 2015 at 6:08 am:

                >Do McCoy signatures interfere with regular add-on signatures?
                I have no idea how “regular add-on signatures” affect XPI file. To make add-on auto-update with McCoy I added two keys to install.rdf: (1) updateURL (which points to update.rdf) and (2) updateKey (based on my ssl-key). Does “regular signing” interfere with that keys?
                Regular auto-update on AMO is incompatible with updateURL and updateKey keys in install.rdf.
                And as I said, McCoy mostly signs (and resigns) external update.rdf (with every new version) and install.rdf ONCE.

             3. Jorge Villalobos wrote on February 18, 2015 at 8:42 am :

                Judging by the docs and what you’re saying, McCoy should continue to work normally. You only need to set an updateURL and add the public key to install.rdf once, and after then all you need to do is change things in update.rdf, which isn’t in the extension file. It should be possible to sign an extension that has metadata from McCoy.

More comments:« Previous 1 2 3 Next »