[Infowarrior] - Firefox update policy: the enterprise is wrong, not Mozilla

[Richard Forno]

Firefox update policy: the enterprise is wrong, not Mozilla

By Peter Bright | Published about 13 hours ago

http://arstechnica.com/business/news/2011/06/firefox-update-policy-the-enterprise-is-wrong-not-mozilla.ars/2
       
Three months ago, Mozilla released the long-awaited Firefox 4. Last week, the organization shipped the follow-up release: Firefox 5. Firefox 5 was the first version of the browser to be released using Mozilla's new Firefox product lifecycle, which would see a new version of the browser shipping every three months or so. The new policy has been publicized for some months, and so the release of Firefox 5 was not itself a big surprise. What has caught many off-guard is the support, or lack thereof. With the release of Firefox 5, Firefox 4—though just three months old—has been end-of-lifed. It won't receive any more updates, patches, or security fixes. Ever. And corporate customers are complaining.

The major problem is testing. Many corporations have in-house Web applications—both custom and third-party—that they access through their Web browsers, and before any new browser upgrade can be deployed to users, it must be tested to verify that it works correctly and doesn't cause any trouble with business-critical applications. With Mozilla's new policy, this kind of testing and validation is essentially impossible: version 5 may contain critical security fixes not found in  version 4, and with version 4 end-of-lifed, the only way to deploy those fixes is to upgrade to version 5. That may not be an issue this time around, but it's all but inevitable that the problem will crop up eventually.

Testing overhead

That makes things awkward for the companies who need to validate browser releases. Rolling out security updates with minimal testing is, in theory, generally pretty safe, because security updates are narrow in scope, and because the risk of the alternative—running a known-exploitable browser—is worse than the risk of something breaking. With those security updates now inextricably linked to other, nonsecurity updates, some enterprise users are expressing the fear that their task is now impossible. The other updates included with the security fixes mean that each release is so large that it must be tested thoroughly, but the rapid release schedule means there's no time to do so.

This has some corporate users of the browser feeling very unhappy. Though the release itself came as little surprise, the consequences it would have for version 4 were not generally understood until it was too late. They didn't realize that they would no longer have access to security fixes for Firefox 4, and now have to test all over again for Firefox 5. And to make matters worse, future updates will probably come out even more frequently; a six week cycle is the goal.

These enterprise customers are plainly unhappy, and some commentators are suggesting that Mozilla is alienating its enterprise customers and in effect signing its own death warrant.

Flawed assumptions

But is this really the right response to take? We're not so sure that it is.

Let's be clear: the enterprise has never been Mozilla's number one priority. If it were, this pair of bugs wouldn't still be open more than half a decade after they were first filed. For enterprises, deployment and patch management using MSIs and configuration control using GPOs, are bread-and-butter stuff. They're a hallmark of enterprise readiness. Internet Explorer—surely the king of enterprise browsers—has this kind of support in spades. Chrome, too has some amount of enterprise support.

I'm sure both of those bugs will be fixed eventually. The work will get done. But enterprise users should take note: they're not the priority, and never have been. This should not be regarded as surprising.

But what of those organizations that use Firefox anyway? How are they going to cope now that they will have to do all this extra testing?

The answer to that is: the same way they always have done. The reality is that Firefox minor updates have never been restricted to pure security fixes. If organizations thought that they could get away with performing only minor testing of the 18 minor updates that Firefox 3.6 has received in just 15 months, they were mistaken. Firefox minor releases have long contained stability and compatibility updates. Sometimes there are even feature changes: 3.6.4 introduced a new system whereby plugins were run in a separate process, and 3.6.9 introduced support for new countermeasures against a certain type of security flaw.

These kinds of changes could absolutely cause compatibility issues with business sites and applications. For businesses that needed to perform extensive validation of the browser before deploying it, then both of these updates would require new validation. And in both cases there was no way of avoiding the new features; there were few "pure security" updates made to 3.6. The implication that the new policy somehow changes something about the nature of Firefox updates—and hence the testing burden—just isn't true.

Combining security fixes with broader compatibility and stability fixes or new features is not unique to Firefox, either; Google does the same for Chrome, and even the latest security update to Internet Explorer 9 includes a minor nonsecurity update that resolves a bug with downloading files. The isolated pure security fix just isn't a feature of the Web browser landscape.

Meaningless numbers

Some have said that the testing problem is a result of Mozilla's decision to bump the major version number—with the implication that their company's testing procedures are driven not by an assessment of what's actually changed but by a mere version number, as if the major version increasing meant that there must be major changes.

Mozilla could have chosen a better mechanism to distinguish between versions than a major version number bump—for example, if they had used a date-based numbering scheme then it's likely that this (flawed) inference would no longer be made. But it didn't, and the result is that an increase of the major version number doesn't necessarily imply major changes under the hood.

Mozilla certainly isn't the first to do this. The next version of the Linux kernel will be version 3.0, from the current 2.6.39.2, but this major version update doesn't denote major changes. It might just as well have been version 2.6.40, or 2.8, or something else entirely; it was simply the preference of Linus Torvalds that the major version should, after many years, be increased.

Nor is Mozilla the first major open source project to use a time-based release model instead of a feature-driven one. The Ubuntu Linux distribution has made twice-annual releases, with major version numbers that increment accordingly, since  its inception. The user community understands this and responds accordingly.

The corporate response to this change in numbering policy should be trivial: base testing on what has changed rather than what the number is. Any other policy has never been consistent with the way the browser is actually updated. At worst, the new update policy is simply highlighting flaws in existing corporate practices.

The Web is the victim

The backlash against the new policy shows a lack of understanding both of Mozilla's priorities and the way it has updated its browser for many years. The new policy doesn't really change the testing implications, and if Firefox was good enough for corporate environments before, it's still good enough today. But the complaints do more than show a lack of understanding of Firefox: they show a lack of understanding of the Web itself.

The Web is a shared medium. It's used for both private and public sites, and the ability to access these sites is dependent on Web browsers understanding a common set of protocols and file formats (many corporate intranet sites may not in fact be accessible from the Internet itself, but the browsers used to access these sites generally have to live in both worlds).

Shared media of all kinds suffer a problem in that the experience of the medium is often constrained by the worst system using that medium. Fire up an 802.11b Wi-Fi device on an 802.11g network, and you'll tend to make the connection slower for everyone: the network drops back to the slower speed to allow the older device to work. TV broadcasters still have to waste valuable bandwidth transmitting a standard definition picture alongside high def, because many TV sets can only use the standard broadcast.

And so it is with the Web. A not-insignificant number of sites have to avoid using HTML, CSS, and JavaScript techniques developed over the last five years, because they have to cater to browsers like Internet Explorer 6 or 7. As the numbers using these browsers drop, sites can slowly adopt newer technology, but this is a slow and painful process. If developers could be sure that only Internet Explorer 9, Firefox 5, and Chrome 13 were in use on the Internet, they would be able to make substantial savings in development and testing, and would have a wealth of additional features available to use.

But they can't assume that, and so they have to avoid desirable features or waste time working around their absence. And a major reason—not the only reason, but a substantial one—is corporate users. Corporate users who can't update their browsers because of some persnickety internal application they have to use, but who then go and use that same browser on the public Internet. By unleashing these obsolete browsers on the world at large, these corporate users make the Web worse for everyone. Web developers have to target the lowest common denominator, and the corporations are making that lowest common denominator that much lower.

The need for speed

In and of itself, this might not be so bad if the Web were a stable, mature platform, one undergoing only minor, incremental improvements. But it isn't; though there was a period in the mid-2000s where W3C, the organization with oversight of Web specifications like HTML and CSS, had rather lost its direction, since 2007 the development of a whole range of specifications under the HTML5 banner has been vigorous.

This work on the specifications has been matched with similar advances in browsers. This in turn has motivated the rapid release schedules of both Chrome and Firefox; instead of sitting on the implementation of some new feature for eighteen months, waiting for the next "significant" release, both Google and Mozilla have decided that it's better to ship features when they're ready. The state of the art of Web browsers is today moving forward at pace not seen since the late 1990s. It would be nice if Web applications could have the freedom to match that progress.

The result is a vast yawning chasm between the very best browsers used with the Web—Firefox 5, Chrome 13—and the very worst—Internet Explorer 6, Internet Explorer 7. And the result of that is that developers have to make the public Web worse for everybody to accommodate these wretched antique browsers. Progress is severely retarded by corporate foot-dragging.

The path Mozilla has taken, the path that enriches the experience of the Web and of Web users, is absolutely the right one for the medium as a whole, and in practice, the negative consequences for corporate customers are not as great as they make out.

Corporate headaches

That doesn't mean that the corporate world has it easy. Companies bought in to the promise of the Web—an easy development platform that would allow robust, rapid deployment of internal applications, without the overheads of managing the thick client applications written in tools such as Visual Basic, the applications that prior to the advent of the Web and the office intranet defined line-of-business software. And for a time, particularly in the post-2001 age of Internet Explorer 6-induced stagnation, it worked out very well for them. That was the only browser that mattered, and since it never changed, it meant that their applications never had to change either.

And so mistakes were made. Some of the mistakes were the same mistakes that existed for conventional applications: disbanding development teams, so programs become orphaned, with nobody around who understands their source code, and letting support and maintenance contracts for third-party software lapse, on the basis that the current version works fine, so who needs to upgrade? Some of the mistakes were new: building applications that were specifically dependent on quirks and unique features of Internet Explorer 6. But even this was understandable; Internet Explorer's market lead looked, for a time, to be unassailable, so where was the harm?

These decisions are now coming back to bite those same companies who bought into the Web concept. These companies never expected the Web, and the browsers that people depend on, to change so rapidly, and they don't have the processes to cope.

Balancing the demands of the public, rapidly developed, exciting, and innovative Web, with the needs of the private, stable, line-of-business Web, is a tough problem, and no browser really bridges the gap between the two worlds. Firefox and Chrome have made the public Web their priority. Each iteration of their browser should be better than the last, and it should be rare that internal applications get broken—at least if those internal applications are sensibly written and developed—but for organizations that need to be able to validate and verify specific browser versions, they're not a good fit.

Internet Explorer, in contrast, has swung very much in the other direction. Microsoft's commitment to support its browser versions for as much as ten years allows corporate customers to settle on a version and ignore everything newer—but this comes at the expense of the public Web. This happens directly—Internet Explorer 9 just isn't as fully featured as Firefox 5 or Chrome 12, so even the latest version of Microsoft's browser is behind the times—and indirectly—because these legacy browsers contaminate and retard the public Web. Beyond that, they're also, arguably, bad for the companies themselves. A company that today needs an Internet Explorer 6-dependent application is in a tough spot. Internet Explorer 6 isn't available on current operating systems, and with each passing day, developer knowledge of such an application will decrease. That IE 6 dependence has to be broken some day, and the longer these companies wait, the harder, more expensive, and more disruptive that change will be.

Neither position is ideal, but indications are that it's the Mozilla and Google strategy that is currying more favor with users. Internet Explorer still has the market share lead, but that share is declining with each passing month. Firefox's share is holding steady, and Chrome's is growing month on month. If the trends of the past year or so continue, Microsoft's browser will lose its majority market share by the end of the year. It'll still retain a plurality share, but it's clear that Redmond's influence on the Web is waning.

Internet Explorer's plodding progress just isn't the right approach if you want to win over users. Though some are suggesting that the new policy is some great opportunity for Internet Explorer to regain some market share, this seems improbable. Organizations that could cope with Firefox before can cope with it now; nothing has changed in that sense.

Back to the desktop?

So what can enterprises do? Longer term, writing Web applications that are sympathetic to the demands placed on the Web is probably the route to take, and that means writing applications that target standards, not browsers. This isn't as simple as it ought to be, as there are still plenty of discrepancies between different browser families, but applications written in this way will be subject to much less disruption from upgrades than applications that depend on quirks.

In the meantime, one technique may be to use different browsers for the intranet and the public Web. Microsoft, for example, has facilities within its MDOP management pack to denote certain URLs, such as those for intranet sites, as requiring a legacy version of Internet Explorer. When this is enabled, you can use Internet Explorer 9 for normal browsing, but the system will switch to legacy Internet Explorer, running within a virtual machine, whenever you attempt to use a legacy intranet site. This doesn't solve the problem entirely—those legacy sites need to be updated eventually—but it can ease the pain. Restricting the legacy browser to intranet sites also somewhat alleviates the need for security fixes for that browser, by greatly reducing its exposure to hostile code.

It's not impossible to see Mozilla offer a similar facility; for example, one release per year could be considered a "long-term" release, and receive security fixes for a period of, say, 12 months. The model here would be similar to that used in the Ubuntu LTS releases: every fourth Ubuntu version is given long-term support, receiving security fixes for an extended period (three years on the desktop, five on the server). Of course, Mozilla itself need not do this work: as an open source project, third parties step in to fill this role, if they believe the enterprise customers are genuinely there. Canonical (the organization that develops Ubuntu) and Red Hat would both be obvious candidates for such a role, as both do such work already for other software packages.

Ultimately, perhaps companies need to re-evaluate their use of the Web itself. If a company really does need to perform extensive validation and verification of its software, perhaps using a browser to deliver that software just isn't appropriate. There are platforms that have a slower pace of evolution, stabler APIs, greater resistance to feature regressions, and long-term support: they're called operating systems. If long-term stability is what you want, perhaps a desktop application is what you need.