Blogger: Craig Roth
There's been some lively internal discussion here about the desirability of automated browser updates for security patches.
An article in Techzoom.net called "Why Silent Updates Boost Security" practically salivates at the thought of patches automatically and instantly being deployed. It praises Google for its 5 hour automated update cycle and states "After 21 days of releasing Google Chrome 1.0.154.48, an exciting 97% share of active Google Chrome 1.x users were using the latest Google Chrome 1.x version."
That excitement wasn't shared over at cnet ("Google issues, then reissues Chrome security fix") where they wrote "Google fixed security holes with a new release of its stable version of Chrome--then released a replacement shortly afterward to prevent a batch of crashes that turned up as well."
I agree with my fellow analysts that the idea of pushing out silent updates does not and should not sit well with enterprise IT. Still, I understand the other point of view too. Just creating a patch and putting it on your website isn’t likely to have much impact. The majority of browser security breaches are targeted at personal PCs who don’t have IT staff to push out updates and don’t even know what a patch is.
One part of the answer then could be creating separate versions of the product (consumer and enterprise) that have different patching strategies. Another part of the answer is that vendors need to take extreme caution when pushing updates directly to anyone's browser. It seems the balance has shifted to quickly trying to close holes rather than the primacy of a personal user's control over their desktop environment. It needs to shift back. Lastly, a middle ground between silent updates and passive posting of patches needs to be used. This includes effective NAGs that let the user know their security patches are outdated (red alert in the titlebar perhaps?), but are not overly disruptive to users.
Note: This is a cross-posting from the KnowledgeForward blog.
Comments