Hacker News new | ask | show | jobs
by roblev 3462 days ago
For many organisations there is a real risk that a browser update will unexpectedly break a key internal application, which could have a catastrophic impact on operations.

The vast majority of large companies will control and test key software updates, balancing the various risks (security patches, obsolescence, operational incidents..).

Not allowing auto-updating to be controlled basically means that the software is not intended to be deployed in enterprises.

3 comments

I prefer Firefox Extended Support Release (ESR)¹ for this though. Every year (currently in March) the current normal Firefox version (that does auto-update) is forked for a new ESR support cycle and made available for acceptance. Three months later if all is stable, it replaces the previous ESR release series, and for a year corporate IT gets a browser that will only be updated with critical (security) updates; no new features, no removal of features. At the end of that year the cycle repeats itself, and you can roll out the new ESR series when you've confirmed everything works as it should.

1: https://www.mozilla.org/en-US/firefox/organizations/

Looking at all these "enterprise" horror stories, I don't think ESR's 1 year is nearly enough.

3 or 5 years might be more suitable.

Most of those horror stories won't happen if you go through the upgrade cycle once a year. A year's worth of chances is manageable for whoever is maintaining the software, three or five years worth of browser features will make the heart of any developer sink.

It is a fallacy to believe that you can stave off updating a modern internet connected browser indefinitely; the IE6/7/8 hell has driven that lesson home in the industry, and security updates are a necessity. If you do need to stay with one particular browser version, then you use a virtual machine or some other properly sandboxed environment to offer it. You can keep running IE6 on Windows XP for as long as you like with a VM that thinks its the year 2003 and which for some reason can only reach http://oldunmaintainedapp.legacy.intranet.example.com. That's fine too (although I would hate to maintain that solution).

my personal take on it : the most you break it, the most you may get money to fix the shit.

So contrary. Guerilla IT. You push for auto update so that they get a motivation to clean shit.

Couldn't orgs just use multiple browsers to reduce risk? With some monitoring of which clients are used, one could remove e.g ie8 support once it's established that every internal product has been used long enough with ie10
This works reasonably well for applications that are used daily or weekly (deprecation notifications help). But then, after you phased out IE8 after months of no problems with IE10, during the holiday period the accountant tries to close the yearly accounts, finds that the form does not work with IE10, and hell breaks loose.
Can't you just build on HTML and JavaScript api's that are widely utilized and accepted? I know before I call something I'm unfamiliar with I'll look up what browsers support it. Most of the problems with IE versions have to do with plugins be it ActiveX or a Java applet. In my mind that isn't a web app but an application packed in a web browser (often so the consultants can call it a web app, "you go to a website to lauch it, see?”)
> Can't you just build on HTML and JavaScript api's that are widely utilized and accepted?

Absolutely. I still have websites that I designed with ie6 in mind that work just fine. But if modern design trends are any indication, it just won't happen. Designers want too many of the new flashy features.