Once, after Microsoft discovered a critical internal bug affecting services, I mentioned a way to fix the hole on an internal forum. Someone did the research and agreed that my suggested fix would close the hole, but it would cause operational problems with 1 percent of customized applications. I said, "Great, let's do it!" My colleagues replied, "We would fire you first" -- because 1 percent of Windows applications accounts for a lot of pissed-off customers. Until that moment, I didn't realize how strict backward-compatibility testing was.
Crazy though it may sound, a company can face a backlash for rolling out patches that are incompatible with popular malware. Microsoft has had more than a few application and software updates that crashed a moderate number of computers because they were infected with malware. The blogosphere went wild, and trade publications featured article after article discussing Microsoft's update and how it crashed computers around the world, along with quotes from disgruntled customers. It's so bad that Microsoft now checks for popular malware prior to applying some of its updates and patches.
Vendors may make software patches better, but they'll never be perfect. For that reason, many admins and end-users choose not to apply patches in a timely manner. Most vendors recommend thorough testing patches before applying them. Some organizations do this, though some do it too well, spending weeks to months before the latest patches are applied. Many other users simply wait a few days to a few weeks to see if any major problems are reported by earlier adopters. And a significant portion of the population simply never applies patches -- ever.
Many people think the SaaS cloud paradigm will change all of this. The traditional idea is that updating will be frequent and invisible, because the vendor can update their centralized software and every end-user will be immediately updated, too. Not so fast.
Numerous cloud vendors are telling customers they can run a version or two behind and select when to start using the latest iteration. Again, this is for operational and, I assume, training reasons. Updating in the cloud should certainly make patching easier to accomplish, but I sadly suspect some of the old patching habits will still be extended in the new world.
To be honest, I'm jealous of Google's default, automatic, silent updating. How does the company get away with it when nearly every other major vendor defaults to end-user or admin approval first? What is the company's secret? Higher-risk tolerance? A stronger-written EULA? And if Google Chrome secures huge market share and is relied upon in production environments, will maintain its install-first, ask-questions later update policies?
These are good questions to ask, because our current patching policies aren't working. We need to do something else. I'm sure all vendors would love to be able to force customers to update quicker. It's more secure, less frustrating in the end, and would lead to lower support costs (because fewer versions would need to be supported).
This story, "Google's stealth updates: Why no one else gets away with it," was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes's Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.