Introducing Extension Signing: A Safer Add-on Experience

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

   I love and recommend Firefox to many, many people. I install it on many machines that I manage for clients as well.

   It is essential that I continue to be able to use add-ons that may no longer be supported and which may not get the signing treatment. Therefore, I strongly request that you make it possible for advanced users to adjust about:config settings to keep current functionality.

   I am getting sick of the Internet police stopping technical people from doing what they know and understand is safe.

   Right now, my UPS network management cards won’t work with Firefox (current version), due to SSL version in use. Said equipment is on my own LAN … I now have to use an alternate browser to manage and monitor my UPS equipment. So, this is another major annoyance, “Internet Police”, please stop being so anal that it stops me from using my preferred browser.

   I totally understand having settings locked down for people whom do not understand the risks … and I lock down as much as I can myself BY MY OWN choice. When I need to open something up, such as allow use of the older SSL on my UPS equipment, then I should be able to do that. And if my tried and true proven add-ons stop working, it is reasonable to allow me to want to re-enable them at my own risk, by my OWN choice once again.

   1. Fx-User wrote on February 14, 2015 at 8:05 pm:

      The middle ground would be to have the configuration located in a root/admin location. about:config is configurable by the user.

      The other way to do it, which is what I do with VBA macros, is to self-sign. Wouldn’t it be ridiculous if I had to submit to Microsoft every VBA code I write for signing. It is just as ridiculous to require this for addons.

      Mozilla should be adding functionality, not subtracting functionality. This signing idea, implemented correctly could be a big help. But, there should be flexibility.

      Otherwise, it will drive more of us to Firefox clones.

2. LJean wrote on February 13, 2015 at 8:50 am:

   So the model of trust is that any add-on signed by Mozilla is trustworthy and any add-on not signed by Mozilla is not trustworthy.

   So your company internal add-on will or will not be presented as trustworthy? Because any system that flags these are untrustworthy is not going to be trusted by the user. This is a significant problem with the current PKI model – trust Verisign but not your own company wrt who is your company.

   Trust models for most people include security and privacy. I understand why you would not block add-ons that may be privacy violating, but this means your definition of trust risks not being aligned with the people whose trust you are seeking.

   We have very different concepts of users’ trust models.

   Ljean

   1. hkmaly wrote on February 20, 2015 at 2:59 am:

      Agree. And there is very simple solution to this problem: allow to add certificates. Instead of requiring all extensions to be signed by mozilla, require that all extension will be signed by new class of certificates, with the administrators being able to change this set of certificates to some THEY actually trust.

      I hope mozilla will rethink this.

3. c4l10s wrote on February 13, 2015 at 11:44 am:

   This again is the completely wrong way.

   You will never be able to protect a “normal” PC user from simply clicking YES and OK on a downloaded program/installer promising some “cutting edge feature” average Joe Clueless will want to install.

   Malware authors will then simply download Firefox Dev Edition in the background and replace the “protected” version with it to run their evil extensions anyway as part of their “Installation Process”.

   Going though the trouble they always will since they make real money with their ads and tracking – you just open the next cat and mice game there.

   All you do is making it harder for legit users and developers of browser additions.

   Better solution:
   – check for new Addons/Plugins on every browser startup/addon hotstart
   – WARN THE USER if something changed
   – give a descriptive info to the User
   – Educating him what an Addon/Plugin actually is (most will fail on the distinction anyway)
   – when it was installed?
   – where did it come from? (AMO / File / unknown?)

   Those that you want to protect need that info and some education – those that do not need the protection will only be annoyed by another “nanny”.

   The only way to make the browser and the web safer is to educate people – do not even think of other ways – you always end in a walled garden driving users away from your product.

4. Frank Stümpel wrote on February 13, 2015 at 12:49 pm:

   I somehow do understand the situation that urged FF devs to this step, but I second the many people here that find this step more problematic than useful. Mozilla always say that their mission is to keep the Internet free, but the planned change is the opposite – take the decision what users can do away from the user. This is exactly the reason why I’d never buy an iThingy or something with Windows Phone/RT, and this is also why I stopped using Google Chrome as my secondary browser when they made their extension store compulsory, and switched to 3rd party Chromium builds and then “Blink” Opera.

   So one big plea (and from the Mozilla people’s announcements I have hope):
   when you make “power user builds” available that have the signing enforcement disabled (or “disableable” – does this word exist? =) – please build them from the same stable branch that you build the branded releases from, and please make them available at the same time and place — Google’s approach in Chrome of “take our restricted stable version or go bleeding edge” is not too helpful…

   BTW, thanks for providing my favourite browser anyway! =)

5. Pete wrote on February 13, 2015 at 4:25 pm:

   Please don’t do this.

   It is taking freedom away from your users, and freedom away from add-on developers.

   You are handing a powerful tool to governments & corporations that will suppress add-ons they don’t like, by compelling you not to sign.

   Mozilla as a platform for freedom & creative software development will be torn to shreds by this.

   Please stop.

6. blueskyy wrote on February 14, 2015 at 12:47 am:

   While the idea is good, I foresee two “problems”, and I certainly hope it would all work out eventually. As others have said before me…

   1. The burden is put on the reviewers. Reading your own code is hard enough, regardless of how simple the project or language is; reading other people’s code is even tougher, especially if it is not commented or structured. Getting proper reviewers, and retaining existing reviewers might become a problem.

   2. For addon developers, ideally, the test (development) environment should be the same as the production environment. Using the Developers Edition, or the Nightly build might create extensions that are incompatible with the latest stable Firefox build.

   Just my 2 cent’s worth of input…

   1. Angly Cat wrote on February 18, 2015 at 4:13 pm:

      1. There is supposed to be an automatic signing, without humans. And if you add-on fails automatic signing, then you could request a manual check. So there won’t be such a big burden on reviewers.

      2. I totally agree with 2. What are they thinking?

7. Mmis1000 wrote on February 14, 2015 at 2:29 am:

   I really doesn’t think this will arrive it’s purpose at all.
   Chrome force extensions to be certified years ago.
   But their are still much malicious extensions.
   And many people look for help to remove them.
   I think.
   No Cracker will stop to hack your browser just because their is a limit.
   They will try to crack it instead.
   And you will lose much more then you get.
   Don’t do that silly thing, please !
   Let anti-malware software do that.

8. Ellendhel wrote on February 14, 2015 at 1:58 pm:

   Please don’t do this, or at least, not that way.

   I’m a sysadmin/netadmin and there is some third-party vendors extensions that I need to install to Mozilla Firefox (my web browser of choice) in order to access and manage some software or hardware equipment. And those extensions will probably never be signed or approved in any way; this is not under my control. I may also have some extensions specific to my workplace that will need to deploy (and as it will not be designed for public use, it will not be signed or approved as well).

   Even if there is a “developer edition” this would not create a consistent, reliable solution, since it will not be the default installation everywhere.

   Please at least consider having an option to let an end-user choose by her/himself (this could be by changing a value in about:config).

   If the things are still defined as described, then I will probably redefine my “web browser of choice”.

9. Fx-User wrote on February 14, 2015 at 7:51 pm:

   It is nice to have a feature addition. But it makes no sense to subtract features. In the case of extension signing, this should be configurable by the computer’s administrator, by the use of a preference setting located in an administrative controlled directory. In Windows, that would normally be c:\Program Files or C:\Program Files (x86). Maybe a setting of 0, 1, or 2 where zero blocks unsigned extensions, one warns, and two ignores.

   I have an extension right now, where the author configured it to use http, whereas I could edit it to use https. If that kind of change makes the extension unusable, I’m not going to be interested in upgrading Firefox to a future version.

   Too bad, because I was looking forward to multiprocess Firefox. Hopefully, some good Samaritan will compile a separate Firefox without this mandatory “improvement”.

10. ANONYMOUS wrote on February 15, 2015 at 1:39 am:

    >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.
    Result: most people install the unbranded version. Corps can’t do that because insurance or some shit and are screwed. People who install random shit still get viruses.

    1. catdog2 wrote on February 17, 2015 at 4:38 am:

       > Result: most people install the unbranded version.
       This may be another Problem. If unbranded or rebranded builds get more widespread because of this nonsense Mozilla more and more looses the ability to take legal action against “bad guys” by using its trademark rights.

11. tank wrote on February 15, 2015 at 4:51 am:

    I plan moving to CyberFox, i am sure they are more friendly about addons too and they have native x64 version of browser too.

12. SPACED wrote on February 15, 2015 at 8:55 am:

    The proposal for this new requirement for Firefox add-ons has not been fully clarified for Thunderbird. Stating that thunderbird is out of scope may still present problems for some add-ons. Some add-ons are universal, they work for thunderbird and firefox. Will this new Mozilla signing of Firefox add-ons preclude continuing to be able to write universal add-ons or will the Mozilla judge and jury for all add-ons hence forth permit universal add-ons and will thunderbird allow the installation of the new Mozilla blessed universal add-ons. So two questions, 1.) will multi application add-ons be accepted? 2.) will the new Mozilla code signed extensions be of a digital signature that will be accepted by thunderbird? [assuming a add-on that is properly defiend for multiple Mozilla applications, US DoD add-on for example.] Thanks in advance for your answer.

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

       Multi-application extensions will continue to work and be accepted. Signed extensions should continue to work in Thunderbird, SeaMonkey, and other applications because we will use a signing feature that has always existed (but few developers used).

       1. SPACED wrote on February 16, 2015 at 11:47 am:

          Thanks for the clarification. From your reply it sounds like Mozilla will be using a signing certificate from a CA that has an anchor in the Mozilla root ca program, those roots that are bundled with the apps. If that is the case, then that makes sense it would be compatible with Thunderbird. It was not initially clear that this was going to be the case.

13. Danial wrote on February 16, 2015 at 1:56 am:

    We don’t want this, so you can send it back to your boss that we said to shove it.

14. Jeanor wrote on February 16, 2015 at 2:19 am:

    I’d like to add also my voice to say please don’t do this.

15. TM wrote on February 16, 2015 at 5:03 am:

    “There won’t be any preferences or command line options to disable this.”

    That’s not acceptable. How would someone test and debug his OWN addon against the release version? Always having it re-signed? Hell no. A developer MUST be able to simply edit a file and restart the browser.

    1. Jorge Villalobos wrote on February 16, 2015 at 9:14 am:

       That’s what the unbranded version is for.

       1. Angly Cat wrote on February 18, 2015 at 4:38 pm:

          As said previously (quote):
          >For addon developers, ideally, the test (development) environment should be the same as the production environment. Using the Developers Edition, or the Nightly build might create extensions that are incompatible with the latest stable Firefox build.

          So you intentionally make the development process more difficult.

    2. John Nagle wrote on February 22, 2015 at 12:53 pm:

       Forcing developers to test in a different Firefox than the production version is not going to work. That’s a headache on the desktop, and a bigger headache on mobile.

       Right now, you can test an add-on on Android by loading it onto a phone from your own web site or from a file. It’s hard to install multiple versions of the same program on a phone. The alternative is setting up a whole Android phone development environment and going into the phone via adb and cfx. This is a difficult way to test a Firefox add-on, and is not totally compatible with normal use.

       Having to use both cfx AND a different version of the browser to test an add-on is totally unacceptable.

       1. Jorge Villalobos wrote on February 23, 2015 at 9:36 am:

          I don’t think we will enforce signing on Firefox for Android since we don’t have the same malware problems as we do on desktop, and also because of the problems you point out.

16. TM wrote on February 16, 2015 at 5:10 am:

    How would you get someone else’s addon signed? For example, I’m using some very old and abandoned addons which still work fine. Of course I want to keep using those, without switching to unbranded or prerelease.

    1. Jorge Villalobos wrote on February 16, 2015 at 9:15 am:

       Old add-ons will probably break in newer versions of Firefox due to e10s anyway. However, if you have an abandoned add-on you want to keep using, you could change the ID or fully fork it and submit it for signing.

17. j wrote on February 16, 2015 at 10:36 am:

    In the year 2021, six years from this decision, the vast majority of computer users will only be able to run software if they have permission from one of less than ten organisations. We almost have all of this in place already:

    * The BIOS will only run signed OSes vis TPM. This mechanism can, if chosen, prohibit operating systems that execure unsigned binaries.

    * Apple, Microsoft and Google control what is permitted on their platforms.

    * And now so too does Mozilla. Obviously no version of Firefox that allows unsigned addons would be signed by any of the platforms to run without the developer mode. (extra charge, eg. Apple Developer Program. 99% of people won’t have)

    TADA! Now the computing of the vast majority of humanity has a handful of gatekeepers. Want a mass audience? Play by the rules. Who makes the rules, who are they accountable to? Few people, accountable to no one. Thanks guys. Way to stand up for the values I mistakenly thought you had.

    Actually, in 2015 it sounds like Firefox OS will be less free than Android. Android at least currently allows unsigned APKs if you follow a warning.

    I used to encourage people to use Firefox over Chrome because it was less under the thumb. Well, that distinction is gone now.

    So is any reason to develop apps for Firefox OS rather than the platforms used by the vast majority.

    Does Mozilla not understand that freedom, decentralisation and openness are their only differentiating factor?

    1. Thibaut Renaux wrote on February 22, 2015 at 3:41 pm:

       I agree wholeheartedly with this comment. I can only voice my concern for this decision, as did a lot of other people. While the intention behind it is understandable and commendable, it is also the same process that a lot of other companies are putting in place in order to lock their customers in their own ecosystem.

       Firefox is different. Or at least, it should be. There should not be a central authority that can control what is or isn’t allowed to run in my browser – or any software or hardware I’m using, for that matter.

       I fear this could lead to an enormous disagreement between the open source community, that Firefox is supposed to represent, and Firefox itself. To the point where a fork could end up being created – one that would follow Firefox’s code closely but would remove this requirement about signed extensions. This wouldn’t be good for anyone involved, yet it is what will happen if this decision comes to pass.

       At least, until Firefox stops being open source, which may happen sooner than we expect, at this rate…

18. coincidence wrote on February 16, 2015 at 10:46 am:

    Why is “users do things despite warnings” a reason to force them not to? Doesn’t their decision to bypass the warning and proceed anyway indicate their willingness to take the risk?

    Please remove the phrase “Let’s build a web that’s open and made by everyone” from the mozilla homepage, it’s disingenuous. As is anything about an “open web”.

    Unless you mean “Open to who and what we choose. For your own good.”

19. SPACED wrote on February 16, 2015 at 12:04 pm:

    If this overly draconian feature is eminent for the standard release of Firefox, could Mozilla consider a enterprise friendly approach for the ESR releases. Features that enforce code signing can be very useful for security, but forcing enterprises to relinquish control of extension code review and determination of what CAs should be accepted for signed extensions will probably not fit many enterprise business models. What would be much more useful is a certificate pinning feature to be configurable by each organization, to bless CA certificates as trusted for extension code signing in their internal Firefox ESR version configured for internal deployment.

20. dmitry_vk wrote on February 17, 2015 at 4:36 am:

    I’m _really_ concerned. I’ve made an addon for firefox that enables firefox remote debugger without user prompt (for automated web application UI tests). I’m pretty sure that this extension doesn’t stand _any_ change of being signed (b/c in general, enabling remote debugger is dangerous and malicious). Does that mean that I won’t have any option of using Firefox for this anymore?

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

       I can see how that is risky, but I don’t think we would consider it to be malicious. We’re trying to set the bar as low as possible, since what we want to prevent is overtly malicious behavior, not risky or experimental things.

21. Goran wrote on February 17, 2015 at 5:26 am:

    Walling off what was up till now open makes FIrefox harder to distinguish against other, corporate backed players in the market.

    Up until now Firefox felt like an open platform that allows developers and users much more freedom than any other platform out there. Never did I feel like I needed to compromise as much as I do now, reading these news. I don’t want to end up having to use Iceweasel or some other project just to get the good without the bad, but I might have to. Maybe it IS time for a completely new browser initiative, just like when I fell in love with project Phoenix and it’s promises.

22. Mr.Yeah wrote on February 17, 2015 at 5:37 am:

    Choose Independent.
    Choose Firefox.

    Well, this text on the homepage of Firefox need to be fixed.

23. cd wrote on February 17, 2015 at 6:27 am:

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

    Does this affect testing the add-ons via `cfx run` from the Addon SDK? If so, should the binary of either Developer Edition, Nightly or an unbranded version be passed to `cfx run`?
    And a last question: the latest Developer Edition versions are higher than stable releases, what happens if something that works on Firefox 37 does not work yet in Firefox 35?

    Thanks
    – c

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

       cfx is on the way out. The new SDK tools should come out sooner than signing. But yes, you will need to perform your tests in one of the versions that support unsigned extensions: Nightly, Dev Edition, or one of the unbranded Beta or Release builds.

24. Jason wrote on February 17, 2015 at 8:11 am:

    Bad idea all around. Do not do this. If you have to, at least provide an obvious opt out. Walled gardens are good for no one. Making users use a developer edition is not the same as allowing common users to bypass walled gardens. I can’t believe the official answer to this problem is “use an unbranded Firefox”.

    Sure, fine enable it by default, but provide an opt out. If you want to write it in big red letters when a user tries to install an external extension, fine whatever just don’t lock down Firefox. User control doesn’t mean Firefox gets to choose what you can install. Maybe put that in your manifesto. Seems like a lot of “follow the pack” going on at Mozilla lately and it makes me sick. Community, FOSS, user freedom. These aren’t bumper stickers.

25. Ben Garner wrote on February 17, 2015 at 6:31 pm:

    CLOSED IS OPEN
    LIBERTY IS RECKLESSNESS
    CONTROL IS FREEDOM

    But it was all right, everything was all right, the struggle was finished. He had won the victory over himself. He loved Mozilla.

26. daofasjdoifj wrote on February 17, 2015 at 7:20 pm:

    I can see the problems right away
    1. You needlessly annoy or waste the time of people who need to use unsigned extensions. They will have to switch to an unbranded version of the browser just to install an addon?
    2. You really wont prevent all malicious extensions because that’s impossible, they will get crafty and eventually sneak by your automated tests and your reviewers.
    3. Burden on reviewers, are they going to dig into each line of code? A manual review of each extension is going to be quite cursory, yeah? I feel for the volunteers and interns who will be wasting their time. Really there are better uses for people’s time.
    4. Addon development is now slower
    5. Unnecessary complexity, headaches for organizations especially
    6. Reputation –> walled garden, dictator, anti-openness

    And you say this new system will make installing addons easier?
    It is already quite convenient to install an addon, really it can’t get much easier.
    But please do continue with your bureaucratic and naive plan to tend the garden, fortunately I cannot be forced to upgrade to the new browser 🙂

27. James Ralph wrote on February 18, 2015 at 12:03 am:

    How will you handle existing addons in the transition period? will there be a warning or only for new installs?

    1. Jorge Villalobos wrote on February 18, 2015 at 8:37 am:

       Good question. I suspect it’ll be a visible warning on installation, and a console warning at runtime.

28. D wrote on February 18, 2015 at 3:25 am:

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

    No. No no no no a thousand times ****ing no.
    What made anyone think this was a good idea?

    At a bare minimum, we need the ability to self-sign add-ons.

    1. Angly Cat wrote on February 18, 2015 at 5:01 pm:

       >At a bare minimum, we need the ability to self-sign add-ons.
       Code Signing Certificates for everyone!

29. Greg Rozelle wrote on February 18, 2015 at 2:07 pm:

    I didn’t read all the comments. My question will the same verification requirements apply to 3rd party builds like cyberfox, waterfox, palemoon, Seamonkey and any build a user might compile?

    1. Jorge Villalobos wrote on February 19, 2015 at 9:11 am:

       Probably not. It depends on them to decide if they want to support it or not, and I believe that there are no plans to support this on Seamonkey or Palemoon. It should be a matter of changing a build flag and a pref value in order to have a build that doesn’t enforce signatures.

       Also, don’t read all the comments 😉

30. smionean wrote on February 19, 2015 at 7:31 am:

    If our extension is already signed with a VeriSign certificat using your signing tool (signal, certutil, etc). Do we need to go with your new review/signing policy?

    Our extension only works if our software is installed (and has binaries and obfuscated javascript code ). How will you test functionality if you don’t have our software. I don’t think my boss want to give a free copy to the reviewer, but he could decide to abandon Firefox support if your new cumbersome policy reject our extension.

    1. Jorge Villalobos wrote on February 19, 2015 at 9:16 am:

       > If our extension is already signed with a VeriSign certificat using your signing tool (signal, certutil, etc). Do we need to go with your new review/signing policy?
       Yes. There won’t be a need to sign the add-on yourselves anymore.

       > Our extension only works if our software is installed (and has binaries and obfuscated javascript code ). How will you test functionality if you don’t have our software.
       We’ll be doing a fairly shallow automated malware check, not a full suite of tests. We only need to verify the add-on isn’t malicious on its own.

31. Jaromir Kuba wrote on February 20, 2015 at 1:47 am:

    I sign my extensions with my code signing certificate. Is this enough, or there will be code signing from Mozilla required? What about extensions developed for corporations, not available to public?

    1. Jorge Villalobos wrote on February 20, 2015 at 3:34 pm:

       Code signing from Mozilla will be required. We have a different solution for non-public extensions that we will announce in the future.

32. JonDo wrote on February 22, 2015 at 7:33 am:

    THIS is your worst idea ever and I’m pretty sure that you will loose with this a lot of users-only the dumb will stay!
    Btw. YOU made FF within the last years unsafer-so that TOR and JAP had to do a lot of work with that!
    I only can hope that there will be a fork as fast as possible.

33. replaceinsteadsideload wrote on February 23, 2015 at 2:37 pm:

    if the attacker can side load stuff then it is often too late.

    I had to work with a completly messed system and saw that the attacker already replaced the browser. (He could also replace firefox by a firefox without the signing requirement, open source 🙂 ).
    I’m curious how addon signing helps against this.
    As a negative side effect I see that malware authors could praise their product as a better firefox or a firefox unlocker.
    And there will be old popular addons and addons whose authors deny to sign their extensions. Think about this. People won’t stop using these extensions and use the hacks.
    => I see it backfiring

    Better idea: make it the default option for windows (you will piss of linux users as they are mainly admins and don’t want/need to be forced) , firefox os (here is this reasonable) and let windows admins decide if they want to enforce this. For example by an option in the installer.

    1. replaceinsteadsideload wrote on February 23, 2015 at 2:40 pm:

       ^firefox os (here is this reasonable)
       but there should be an opt out (like in android)

34. SMarmotte wrote on February 24, 2015 at 2:06 pm:

    “There won’t be any preferences or command line options to disable this.”
    … so …
    There won’t be any way to prevent people to stop using Firefox.

    Did you think of internal company firefox extensions? Due to confidentiality, those extensions will never be sent to Mozilla to get signed. They will just stop working.

    You are making a big mistake.
    Please, don’t kill the fox.

35. Mmis1000 wrote on February 25, 2015 at 1:59 am:

    Power tends to corrupt, absolute power corrupt absolutely.
    Chrome remove any video download extension on their web store after they applied their force code signing.

    If mozilla applied this, they will be the only one that can determine what extensions can use on the firefox, just like google.
    Can mozilla ensure they will determine the plugin is ok or not *only* based on if it will stole the data or corrupt use browser？
    Will they prevent the plugin from going to AMO because some company accuse them？
    Will the code review be public and not let any one cut in line just because the reviewer is the coder’s friend or some reason like that.
    Will the extension be prevented from going to AMO due to organization or personal reason？

    Can mozilla persist from certain pressure like google…etc？

    1. Jorge Villalobos wrote on February 25, 2015 at 8:05 am:

       We can already block any extension from being installed in Firefox, so this isn’t something that is going to change because of the introduction of signing.

       1. mmis1000 wrote on February 25, 2015 at 6:17 pm:

          The problem is not block or not.
          Is caused by Mozilla is the one only allow to sign that.
          Without a fair process, such model can lead to a uncontrollable mess, just lIke chrome.
          And finally make many developers leave from them.
          Does Mozilla has the required factors to prevent from such problem?
          Though the model sounds great ,does Mozilla really ready for that?

          1. Jorge Villalobos wrote on February 26, 2015 at 8:28 am:

             Well, add-on malware is currently an uncontrollable mess, which is why we feel the need to take action. I still think blocklisting is an important point to bring up, since we are already capable of disabling any extension, not only the ones on AMO. The potential abuses many people have brought up can already occur in the current system.

             1. Mmis1000 wrote on February 27, 2015 at 3:02 am:

                Why you are keeping talk about to block the extentions should be blocked？
                That is not the problem, it is fine to block malwares.
                My question is “Is there a such process prevent extension shouldn’t be blocked from being blocked？”.
                Google do the wrong way, they block everything they didn’t like, not just malware.
                What about mozilla？

36. Daneel wrote on February 25, 2015 at 4:11 am:

    This is so wrong, what are you doing Mozilla ?
    Anyone should be able to configurate and install add-ons in anyway we want. That’s why we use Mozilla and not other browsers. Don’t treat us as toddlers. Warn us, that’s good, but let us do what we want after that. Do not begin controling.

37. toady wrote on February 25, 2015 at 5:06 pm:

    I have a question,

    When a user goes to install his\her favorite addon and it gets refused because its not signed and they find out they need ether an unbranded Firefox or a developer build, With the unbranded been the current release version won’t everyone be installing unbranded firefox to the level unsigned addons are aloud in this build negating the whole point of forcing the addons to be sign.

    All i can see is a larger issue of unbranded Firefox full of malicious addons and every user installing the unbranded firefox because there addons are not installing in the official.

    Has someone overlooked this?

    There already is an addon review backlog for 36.0

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

       We don’t expect most people to go through the effort of installing the unbranded build. Since it’s meant for developers, most people won’t even be aware it exists.

       1. Felixwu wrote on February 26, 2015 at 11:38 pm:

          Please provide a link to get unbranded builds, and the other versions that will run unsigned extentions. Thanks.

          1. Jorge Villalobos wrote on March 2, 2015 at 10:10 am:

             The unbranded builds aren’t available yet. You can use these links for Developer Edition and Nightly.

             1. Rob wrote on March 2, 2015 at 3:11 pm:

                I’m also using my own certificate, to proof the authenticity of my addon, and to get my name to appear on it (instead of “Author not verified”).

                With the new change, will I still be able to show my name at the installation dialog?
                What’s the use of the signature if AMO is going to replace it anyway?
                is it possible to apply multiple signatures:
                1. Optional: The addon author’s signature (to get the addon author’s name to appear).
                2. Required: AMO’s signature (to get Firefox to accept the addon).

             2. Jorge Villalobos wrote on March 4, 2015 at 2:00 pm:

                The install UI will change (see gif in the post, though I admit it changes very quickly), removing the identity bit. Since all add-ons will be signed by Mozilla and that’s not to assert ownership, it doesn’t make sense to display the signer. It won’t be possible to apply multiple signatures, since the current system only supports one.

38. Giuseppe Randazzo wrote on February 26, 2015 at 4:57 am:

    Mozilla, don’t do that!

    Actually i don’t understand exactly, why this is going to be implemented.. It takes away the freedom of customizing and extending this browser…

    Why don’t you implement a warning, when an user is installing a extension from an unknown site ?

    For me, this isn’t the right way! Especially as addon developer this will make self-distributed extensions harder to get..

    This is the consequence of open software…

39. f763285 wrote on March 1, 2015 at 9:47 am:

    nice. instead of fixing constant huge memory leaks, graphic acceleration problems, sandboxing flash bugs and “webrtc ip leak” in “hello” you try to add yet
    another useless “feature”.

40. A_Firefox_User wrote on March 2, 2015 at 3:56 pm:

    The existing blocklist only affects those extensions which Mozilla puts on the blocklist. The blocklist is a download, so users can reliably identify all of the extensions that Mozilla is trying to block. Users who do not want to use the blocklist can go into about:config and disable the feature.

    The new proposal affects all extensions. It will be more difficult if not impossible for users to reliably identify all of the extensions that Mozilla refuses to sign. Users cannot enable/disable this feature as they see fit.

    Such differences make the new proposal of greater concern. Much greater concern once you factor in the “extensions must be submitted to Mozilla for approval” aspect.

    1. Jorge Villalobos wrote on March 4, 2015 at 2:06 pm:

       That’s true for extensions you don’t know about, or for which there isn’t much information about them online. However, if there were an extension that did something controversial like bypassing site / government restrictions in some way and we refused to sign it, it seems fairly certain that it would make the news. It’s true that it’s easier to identify blocked add-ons now because of the blocklist being completely downloaded, but that’s just an implementation detail that could change in the future (we don’t have any specific plans, but the blocklist has grown to a point where we might reconsider the ‘download all of it’ part). With either approach, given an extension, you should be able to easily figure out if we have allowed it to be distributed or not, in that it’s either blocklisted or not, or signed or not.

41. lipki wrote on March 4, 2015 at 4:59 am:

    Mais what !
    On n’est pas en avril, c’est quoi cette histoire ?

42. Mmis1000 wrote on March 5, 2015 at 2:01 am:

    Why you are keeping talk about to block the extentions should be blocked？
    That is not the problem, it is fine to block malwares.

    My question is “Is there a such process prevent extension shouldn’t be blocked from being blocked？”.
    Google do the wrong way, they block everything they didn’t like, not just malware.
    What about mozilla？
    How to make sure mozilla won’t “misblock” some extensions due to money from google, pressure from some delelpoer… etc？

    1. Giuseppe Randazzo wrote on March 5, 2015 at 4:04 am:

       Sadly money rules the world… Mozilla will destroy itself with this!

    2. Jorge Villalobos wrote on March 5, 2015 at 9:47 am:

       As explained in the post, there are various ways in which you will be able to freely use unsigned extensions. If some extension were misblocked, there’s nothing stopping a developer from making that public, and there’s nothing stopping users from testing the extension themselves and letting us know they disagree with our decision. We have a public set of rules to determine if an add-on should be accepted or not, and we will update this blog if there are any changes to them. Our reviewer team is open to volunteer contributions (and most contributions come from volunteers). I know this doesn’t guarantee misuse, but we do take openness and transparency very seriously.

       1. Shelaine wrote on March 8, 2015 at 5:16 am:

          So, can I assume the issue with yahoo tool bar being broken is because of this? No one has been able to get answers from them so trying here. Many many people are frustrated as hell. If this isn’t the case never mind. If it is, would be nice to be able to pass that on to fellow users who are tearing their hair out. Thank you.

          1. Jorge Villalobos wrote on March 9, 2015 at 10:00 am:

             None of this has been implemented yet. The problems you’re experiencing with Yahoo Toolbar are unrelated. I recommend you contact Yahoo! about it.

43. Fx-User wrote on March 6, 2015 at 9:58 am:

    Here’s a recent thing as to why I might want to go into an extension and fiddle around with it. In the FX36 beta, there was a note indicating work on Media Extensions so that html5 video would play on Youtube.

    I didn’t see it on the final, but I went into the preferences beginning with media.mediasource and enabled all of them, and I’m getting VP9 video, which conserves bandwidth. But no longer supported RequestPolicy can’t handle the “mediasource:” prefix that Youtube uses. (I know that someone is trying to take over the RequestPolicy addon and get this to work, but it isn’t working today.)

    I haven’t had the time to fiddle around with this addon, but I would like the ability to do so. But, what I’m hearing is that I’ll need to go through some bureaucracy to use my changes in the addon on my browser, and that is ridiculous.

    That is the general sentiment I’m seeing out of all of these comments here. This obstinacy to putting in a preference whether signing should be mandatory or not reminds me of a OS vendor that decided to eliminate the Start menu in their latest OS release. In both cases, it is a matter of not listening to their users.

    I think at the very least, there should be a preference file in an administratively controlled location. The best way would be to have self signing.

    The PC manaufacture Lenovo did a wonderful thing in that they put a root certificate into Firefox on their customer’s PC. The reason why it is wonderful is, in order to remove it, they have compiled the NSS utilities here:
    https://github.com/lenovo-inc/superfishremoval/tree/master/SuperFishRemovalTool/NSS

    I have the NSS certutil for example. So, I would need to make a code signing certificate and self sign extensions with it. That is the approach I want, Mozilla and self signing, with nothing unsigned running.

    So, this extension signing has a lot of swing in it. Properly implemented, it could be wonderful. Poorly implemented will be terrible. No implementation is better than a poor, bureaucratic implementation.

44. Antonin wrote on March 9, 2015 at 6:53 am:

    Please don’t lock users like it.
    More security is good, but you have to give Firefox users a way to install what they want.

    Many of us use Firefox for its principles. Don’t ruin that !

45. Bartimaeus wrote on March 10, 2015 at 2:59 pm:

    Does anyone here remember Microsoft’s driver-signing scheme? It proved clunky and unworkable and every driver from here to kingdom come ended up coming with a note saying, “your computer will complain about this not being signed, ignore it”.

    I really hope Mozilla isn’t pulling a Microsoft here.

46. SAH wrote on March 11, 2015 at 2:36 pm:

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

    How do I submit my self-hosted (not on AMO) add-on for signing? I have:
    – Registered at https://addons.mozilla.org
    – Stepped through the “Submit a New Add-on” process, but did not complete step 6. “Select a review process.” The only two options are Full or Preliminary Review. I’m afraid that choosing either one will result in my add-on being published, which I don’t want to happen. I simply want Mozilla to sign my add-on and send it back to me.

    How do I accomplish that? I would expect there to be a “Do not publish” option.

    Thanks

    1. Jorge Villalobos wrote on March 12, 2015 at 9:45 am:

       The AMO part of this isn’t done yet. We will announce when you can submit your add-on for signing.

47. LuckyBastard wrote on March 12, 2015 at 4:52 am:

    The end of freedom comes under the guise of safety. Thanks for the years of freedom, but I don’t need or want your “safety”. SELLOUTS!

    They are conforming to mass influence, by abandoning thier principles.
    Specifically Mozilla principles:

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

    You are restricting my ability to choose how I experience the internet, by policing what I can install on my browser.

    #7: Free and open source software promotes the development of the Internet as a public resource.

    Open source tenant #5:

    No Discrimination Against Persons or Groups

    The license must not discriminate against any person or group
    of persons.

    Rationale: In order to get the maximum benefit from
    the process, the maximum diversity of persons and
    groups should be equally eligible to contribute to open
    sources. Therefore we forbid any open-source license
    from locking anybody out of the process.

    Tenant #7.

    Distribution of License

    The rights attached to the program must apply to all to
    whom the program is redistributed without the need
    for execution of an additional license by those parties.

    Rationale: This clause is intended to forbid closing up
    software by indirect means.

    Tenant #9.

    License Must Not Restrict Other Software

    The license must not place restrictions on other software that
    is distributed along with the licensed software. For example,
    the license must not insist that all other programs distributed on
    the same medium must be open-source software.

    Rationale: Distributors of open-source software have the
    right to make their own choices about their own software.

    Tenant #10.

    License Must Be Technology-Neutral

    No provision of the license may be predicated on any
    individual technology or style of interface.

    #9: Transparent community-based processes promote participation, accountability and trust.

    This one is more of a personal feeling of lack of transparency, I have been losing trust in them for some time.

    I haven’t completely abandoned hope that they will right this ship, but if they refuse to stick to the principles and tenants that got them where they are today, then I wish them a swift and painless fall from grace, and into obscurity.

More comments:« Previous 1 2 3