and on the developers of those add-ons.
And hands over ownership of its add-ons ecosystem to Google by pledging conformance to the extensions API Google owns.
And does its bomb drop in the Friday news void.
https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons
The comments on the blog posts are illuminating and outline the many real negative consequences.
I used to feel sorry for people using other browsers that only let you run approved add-ons.
Hmm, wonder what this means for Pale Moon.
I use the developers edition on my work computer - I think that it is at version 42. They rolled this out a couple weeks ago - at least for now, one can disable it via about: config.
I think they are looking at supporting both forms of add-ons
http://forum.palemoon.org/viewtopic.php?f=26&t=8756#p62147
Iâm switching to Pale Moon myself, this looks like these changes will break things for me and I never liked using Chrome that much.
I suspect that FFâs add-on structure could use some serious tightening(as much as I love their number and breadth, they pretty much have the run of the place once installed); but the âconsumerizationâ of cryptographic signature handling is one of the things that makes me livid.
Cryptographic signatures are enormously powerful tools for security. Much easier to verifiy that a file hasnât been tampered with on its way to you, originates from a given party, and so on. However, if you do not control who gets to be in the list of âtrustedâ keys, you are a tivoized consumer serf.
Unfortunately, the answer always seems to be either âNope, you are a tivoized consumer serfâ(Apple leading the charge on that one); or âWell, fine, be that way. You can turn it off and go live in a cave.â(Googleâs preferred approach, and apparently Mozillaâs here).
I donât want to turn off cryptographic verification; I just want to be the one who controls the list of trusted signers. So long as I can do that, itâs a fortress. If I no longer can, itâs a prison.
yo, @albill - provocative language aside, as a Mozilla insider-who-doesnât-work-on-extensions â whatâs your viewpoint?
(May I say that this was the first I had heard of Electrolyis, and I am thrilled. )
This also sounds like another nail in the coffin of XUL. I like XUL. I donât use it. But I used to wish I did.
Yes, Iâm definitely being critical on purpose. If inflammatory language lights some fires under some backsides, thatâs a good thing. The proposal is breathtaking in its scope of destruction â weâre talking man-centuries of work being thrown away â and a lot of it is justified as âyou shouldnât want that anywayâ, the opposite of user choice. This is terrible.
(I realize Iâm not the only person capable of forming an opinion for him/herself.)
This isnât even remotely accurate of a description of whatâs actually going on (by you).
You realize Pale Moon is a hand maintained fork based off of ESR 31 Firefox. It isnât remotely as secure as the mainline Firefox in my opinion.
Iâm not clear on whatâs being âthrown awayâ - thereâs a new extension API being introduced. Great!
But the old model is not being deprecated, AFAICT.
The signing, as I understand it, seems to be a nuisance. If I build an extension and want to distribute it to 5 of my friends - it has to be reviewed in the Mozilla reviewers-queue to be signed, or all 5 of my friends have to be running special versions of Firefox to avoid signing?
Reviewing and certifying that an extension is Mozilla-certified Malware Free! is awesome, but insisting that everything be reviewed and certified is not awesome. (If that is indeed what is going to happen.)
All the above typed before I saw @albill responding. Edited not in response to anything he said, but wanted to make it clear this is NOT in response to anything he said.
Okay, maybe not as much of a nuisance as I thought:
##How does the signing process work for unlisted add-ons?
For unlisted add-ons, files submitted for signing will go through
an automated review process. If they pass this review, they are
automatically signed and a download link is sent back to the developer.
This process should normally take seconds. If the file doesnât pass
review, the developer will have the option to request a manual review,
which should take less than two days. This is not the same process that
currently applies to AMO add-ons, which has been typically slower. (source)
The signing part is necessary work because of the ability of add-ons to do very powerful things. There has been a need to tighten things down for a long time because some folks will just install any olâ thing without inspection.
The new API work, which is a ways out so people shouldnât get too paranoid or angry just yet, is necessary. We have a decade+ old technology which is holding back things like electrolysis and other necessary improvements to Firefox for speed and security. A lot of add on developers rely on private or non-public APIs that were never meant to be used longterm by third parties (or relied on to not change or work, which is why they were private APIs). The move to standardize on public APIs, hopefully supported by multiple browsers, will actually make add on development easier on the long run.
The problem here, really, is a loud chunk of users are reactionary about any changes at all, regardless of why, and will bitch and moan forever about how Mozilla is betraying them because ofâŚchanges. The reality is that folks within the project are also developers, have thought about these changes, and they arenât done whimsically just to piss off old users.
This really isnât my area though. I run a security fuzzing team and I work on security issues as the platform security program manager. One of my friends is working on some of this, which is why I know anything (that and all the doom saying on reddit and the like).
But it wonât because youâre just ranting, not making a reasoned argument and this isnât a Mozilla forum or email list, just Boing Boing, so folks arenât going to carry your water back to Mozilla to make your arguments (whatever they are) for you.
If you want a say in what Mozilla does, you need to be part of the Mozilla Project and contribute to it, really. Ranting on the Internet is neither.
Unfortunately, that just means that malware authors will host the add-ons on their own sites and then phish for users to get them to install them from there. Itâs all in or nothing when it comes to this sort of thing.
A more even take on things:
I think this sort of thing can be really good in the long run, mobile apps have to be signed, most modern developers are familiar with working with this sort of requirement.
Android respects user freedom and although it only allows signed apps by default, developers and power users can go into the settings and turn that off at their own risk. This is a perfect balance of benefit and freedom, imho. OSX does a similar thing with Gatekeeper, only signed apps allowed by default but again developers and power users can allow all apps at their own risk.
iOS goes the other other way, and eliminates any possibility of user choice, which I donât think is the right decision, and eliminates all freedoms except for those that apple approves. it is a d*ck move.
It is my understanding that Firefox Developer edition will continue to allow unsigned plugins if you switch the setting in the about:config (GOOD), but that regular Firefox will not have that option (BAD). If that is the case, then Iâd be disappointed in Firefox which has up until now been a bastion of these types of freedoms. If they are keeping that about:config setting in both versions then I donât see any issue, most users will only be able to install signed plugins, and power users still have the freedom to do more at their own risk/discretion, a win-win. Do you know if this is the case? Thoughts? thanks.
as a reminder of how much the strict signing only requirement sucksâŚif iOS allowed unsigned apps to be installed, mozilla could release a real version of firefox for iOS, and google could release a real version of Chrome for iOS instead of the âexperienceâ BS that they have now which is just a skin on top of the safari engine. iOS users have no real choice in browsers because of appleâs requirement for all browsers to be built using the safari engine under the hood. apples iOS signing policy prevents any real alternatives unless you jailbreak. Mozilla has made some public comments about their opinion on this. I hope they remember this as they form their plans going forward.
Signing = GOOD.
No Ability to Bypass Signing = BAD.
Not my decision (not even my department) and well above my pay grade.
I, personally, agree though I do realize that if it is easy to turn off signing requirements, every group (like the EFF until recently) that doesnât want to deal with the signing process for their add-on would just tell users to turn off the signature check and weâd be back to square one. Every developer who canât be bothered to deal with it will route around it.
Yeah, I know it isnât up to you, Iâm only bouncing this off you because you are closest to an insider opinion as we have here. 
I realize this isnât your department and you have no say in the decisions. Do you know the best way to leave feedback about these choices that will be heard?
Mozillaâs obligation is to provide a secure platform, not to force users to leave security on. They can provide a popup dialog/disclaimer explaining the risk that has as much warning as they see fit, but making it difficult is the wrong choice. The thing about true freedom is that users who opt out should have every right to do so. That is what âAt you own riskâ is for, after a user opts out it isnât mozillaâs problem anymore.
If a developer tries and route around it, users can decide for themselves if the risk is worth the benefit. If the warning when switching it off is sufficient, user pressure/feedback will make most users look for alternatives or pressure for signing or theyâll just do without.
Informed Choice is a crucial user freedom. Making that difficult or in other ways restricting the choice rather then making it easy but offering clear information, is the wrong choice, imho.
In the real world Iâd prefer the ability to opt out per plugin, which is even better then having to enable/disable the entire thing. I also like how google states what each extension (plugin) has the permission to do, and having the ability to enable/disable those permission on an item by item basis. Iâd like to see something like that in Firefox ideally.
Well, thatâs because Google already has a different extension architecture. Frankly, right now, if you install an extension with a binary component in Firefox, it can do whatever it wants within some rather large limits. There are no granulated controls. The move to a public API based new system is much more likely to allow Firefox to have those kinds of granular controls but some people are in an uproar about this move.
As to dialogs and trusting the user, I hear you. As someone who works professionally in security, I have a petty low opinion of the amount of informed decision making most users will do. Many (most?) will do what an informed third party tells them to do if it is the means to an end (getting the extension they want). There is a tradeoff here and most choices are bad.
BTW, âextensionâ and âpluginâ in Firefox are not interchangeable terms. Weâre talking about extensions. Plugins are binary addons of things like Flash or Silverlight.
