How a Firefox update just damaged practical security

December 15, 2014

Recently, Mozilla pushed out Firefox 34 as one of their periodic regular Firefox updates. Unfortunately this shipped with a known incompatible change that broke several extensions, including the popular Flashblock extension. Mozilla had known about this problem for months before the release; in fact the bug report was essentially filed immediately after the change in question landed in the tree, and the breakage was known when the change was proposed. Mozilla people didn't care enough to do anything in particular about this beyond (I think) blacklisting the extension as non-functional in Firefox 34.

I'm sure that this made sense internally in Mozilla and was justified at the time. But in practice this was a terrible decision, one that's undoubtedly damaged pragmatic Firefox security for some time to come. Given that addons create a new browser, the practical effect of this decision is that Firefox's automatic update to Firefox 34 broke people's browsers. When your automatic update breaks people's browsers, congratulations, you have just trained them to turn your updates off. And turning automatic updates off has very serious security impacts.

The real world effect of Mozilla's decision is that Mozilla has now trained some number of users that if they let Mozilla update Firefox, things break. Since users hate having things break, they're going to stop allowing those updates to happen, which will leave them exposed to real Firefox security vulnerabilities that future updates would fix (and we can be confident that there will be such updates). Mozilla did this damage not for a security critical change but for a long term cleanup that they decided was nice to have.

(Note that Mozilla could have taken a number of methods to fix the popular extensions that were known to be broken by this change, since the actual change required to extensions is extremely minimal.)

I don't blame Mozilla for making the initial change; trying to make this change was sensible. I do blame Mozilla's release process for allowing this release to happen knowing that it broke popular extensions and doing nothing significant about it, because Mozilla's release process certainly should care about the security impact of Mozilla's decisions.

Comments on this page:

By Ewen McNeill at 2014-12-15 23:30:22:

FWIW, this "they're all major version updates, so we can break the API" rapid churn is one of the reasons that I stick with the LTS -- I mean ESR -- Firefox releases. It does at least get periodic security updates, but the "major version change" treadmill is slowed to a level where it's actually possible to keep up. I think it's preferably to the "random working release that we never update" approach which other people seem to adopt, at least from a security point of view.

It also seems to me that Mozilla -- or at least Firefox -- don't really want to be a "platform" (ie, stable thing on which others build their things, such as plugins). From several angles the success of Firefox plugins seems almost accidental (including from what I've read the internal API design -- it appears pretty tightly coupled to internal implementation choices in a bunch of ways, and thus a fairly fragile/easily broken API). (And I do understand not wanting to be a "stable platform" for others -- it's a bunch of work. But that's also where the value comes from: it's a bunch of work others do not have to do.)


Written on 15 December 2014.
« Why your 64-bit Go programs may have a huge virtual size
Does having a separate daemon manager help system resilience? »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Dec 15 22:14:18 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.