Add-on Security Restrictions Landed

I have just checked in Bug 378216, and wanted to give a quick heads up on it.

What this means is that we are now enforcing a security restriction on all add-ons. To be specific, if an add-on does not provide a secure method of auto-updating then by default Firefox will refuse to install the add-on. If you have add-ons already installed that are insecure in this way then they will be automatically disabled.

The good news is that addons.mozilla.org already uses SSL for it’s updates, so any add-ons you have installed from there will be unaffected by this change. Equally any add-on authors who use SSL on their site, their add-ons will be unaffected. Personally I found 2 of my add-ons were disabled by it, that’s 2 out of nearly 20, so hopefully you won’t see a major impact.

For add-on authors there is an alternate way to provide secure updates without investing in an SSL key involving digital signatures, unfortunately we’ve had to hold off on providing the software to make that possible until the backend changes were complete and reviewed. I hope to have something usable available not too long after M8 is released. Keep an eye on this blog for an update on that.

If you want to see more of the specifics the best place to look is probably at the wiki page. This is all based around the discussions I started on various forums and newsgroups. Hopefully it’s not too much of a surprise to the add-on authors out there, if it is then I apologise, I tried to get the word out as best I could.

Practice what you Preach

One of the main parts of my work for Mozilla at the moment is about securing add-on updates. The spec is now pretty near complete and the implementation is also pretty much complete so hopefully we can start pushing out the necessary tools to add-on authors real soon then land the work shortly after.

Of course it wouldn’t be right for me to push this out without first making my own extensions comply with the new requirements. So today I am rolling out updates to all of them, mostly just changing the update url to an SSL one, though a couple of the extensions (Nightly Tester Tools and /Find Bar/) have some additional updates.

Using SSL really will be the easiest way of hosting secure updates for your extensions and I urge you to use it. Assuming you have a sensible hosting package, adding SSL is really not as expensive as many expect. Godaddy offer SSL certificates for $18 per year (minimum of 2 years) and if you are like me and hosting open source extensions then you can get the first year for free (though that seems to take a few weeks longer than if you pay). It’s also pretty simple to set up assuming you have a decent webhost, Dreamhost just has one form to fill in.

It turns out that the hardest part of getting SSL was fixing the bugs in my CMS since it’s current version had never been used in an SSL environment before 😉

Securing Add-on Updates

Since the disclosure of potential vulnerabilities in the way Firefox (and other Mozilla applications) automatically update your add-ons we have been discussing how to tighten up the system in a way that is hopefully unnoticeable to users and not much extra work for add-on authors.

After a process of listening to authors on the newsgroups, forums and by email we now have a rough proposal of what changes we are looking to make. There’s still a few minor details to be ironed out of course. This is mainly of interest to add-on authors since there is an impact depending on how you host your updates. I’ve started threads on the newsgroup and forums so if you want to discuss the proposal there then that’d be good. I’d prefer it if you didn’t edit the main page of the wiki but feel free to stick small comments onto the discussion page.

Why would you want a decent password? It’s only money!

I guess it goes without saying that I’m fairly technically literate and as such I’m pretty well versed in both what makes a strong password and actually using them. I actually have a pair of passwords, one that I use for what I consider my more important logins (company accounts, servers and the like), and another that is for lesser services that if I lost or it got hacked then it wouldn’t be a major compromise of anything.

Given this it’s always particularly disappointing when I find something that I really want to use a strong password for but can’t, because the service in question can’t handle how strong my password is.

Take my new bank account with Lloyds TSB. The password for the internet banking is 6-15 characters, must contains letters and numbers, but cannot contain any spaces or anything non-alphanumeric. Bang goes about 4 characters from my strong password.

Lloyds aren’t alone either. I also have a savings account with Citibank. To log in to their online banking I am not allowed to type in my password by hand, instead I must use an onscreen keyboard with my mouse. Now I’m not quite sure what this is meant to serve, all it does is enter the characters into a regular html input box, you know, easily readable from an add-on or other form of spyware. And even worse the keyboard gives me just 51 possible characters to choose. At least Lloyds let me use both upper and lower case!

Maybe all these places having quite different restrictions on what characters I can use in my password is a cunning ploy to make me use a different password everywhere, but I find it a little disturbing that I’m able to use a stronger password with my online pizza delivery place than with my bank accounts holding thousands of pounds of savings.