Adobe has taken a lot of heat lately for the (in)security of its two most popular consumer products, Reader and Flash Player. While much of the criticism may be justified, it’s also important to give credit for some positive steps that Brad Arkin and the rest of the Adobe security team are taking to protect consumers.

One such step is the recent release of an improved automatic update mechanism in Reader and Acrobat. The purpose of this new mechanism “is to keep end-users up-to-date in a much more streamlined and automated way,” according to a recent Adobe blog post. Importantly, the new mechanism respects user choice by continuing to observe the update settings that the user previously set (or left at their defaults) in Reader/Acrobat.

In this later blog post, Adobe’s Steve Gottwals points out that the current default setting is “Automatically download updates, but let me choose when to install them,” while the optimal setting for user security is “Automatically install updates.” To Adobe’s credit, they’re exploring ways to encourage users to opt into this more aggressive update setting, but without changing it surreptitiously.

This afternoon, we hosted a productive web chat about automatic updates and their impact on user security and control. A few interesting themes emerged during the conversation:

• There is an important distinction to be made between updates that fix vulnerabilities and those that add or change product features. The former can/should be treated as a public health issue, especially when one user’s issue can lead to other users being hurt (e.g., a browser vulnerability that could allow a computer to become a spambot). The consensus of the participants seemed to be that automatic updates to fix bugs or vulnerabilities should be pushed more aggressively and should require a lower level of disclosure and user interaction than feature updates.
• Enterprises and other managed computing environments (e.g., university computer labs, government netowrks, etc.) experience automatic updates very differently than end users. In these environments, IT staff may need to control bandwidth usage and to test applications for compatibility with internal systems prior to pushing updates. Software vendors can help IT staff by providing tools and configuration options that facilitate centralized update management. In addition, there was a call for a standardized cross-vendor protocol to make this easier.
• Users in areas with low bandwidth (rural areas, developing countries, etc.) often disable auto-update features to conserve bandwidth and, as a result, use insecure product versions longer than users with ready access to high-speed broadband. Software vendors can help by minimizing the bandwidth necessary for patches (e.g., distributing differential updates instead of full new product versions), clearly distinguishing between security fixes and feature updates, and providing options for bandwidth throttling. Educating users about these bandwidth-saving features when they are available would increase user participation.
• In the case of applications targeted at individual (non-enterprise) users, there was little concern about disclosure of automatic updates as they relate to bug and security fixes. On the other hand, participants felt that feature updates should be clearly distinguished as such and that an auto-update system that plans to include feature updates should disclose this behaivor.
• There was consensus that, for a variety of reasons, including those alluded to above regarding enterprise and low-bandwidth environments, users should have the ability to disable auto-update features. That said, it was pointed out that the option to opt out of security updates might be better hidden in a configuration menu than presented as a choice at installation, which might lead to people opting out too frequently.
• Consensus was clear that automatic security update mechanisms should not be used to enforce software licensing, as these create a barrier to people fixing security vulnerabilities that may affect not only them, but also others on the network/Internet.
• It was also agreed that automatic updaters should not be used to push other products on users, as this can decrease trust in the update system.

A transcript of the text-based portion of the chat can be found here. Unfortunately, I neglected to record the audio portion, so the transcript is missing some of the great comments that people made, but the text transcript does capture many important points. Speaking of comments, please share your additional thoughts on this topic here in the blog comments, or feel free to e-mail us at contact@stopbadware.org.

Don’t forget to register for Wednesday’s web chat about automatic update mechanisms and their effect on end user security and control. More information about the topic and how to register can be found in the original blog post.

In the past couple of years, auto-update mechanisms that allow software applications to check for and install patches or new versions have become far more prevalent. Some software vendors have looked to push auto-updaters beyond the traditional “an update is available, do you want to install it?” format. Last year, Apple began using its updater to push additional software applications. Google’s Chrome browser silently installs updates, including new major versions, with no user interaction or notice. A new updater for Adobe Reader appears to be a hybrid of Chrome’s silent installer and more tradiitonal updaters.

On Wednesday, Feburary, 10, at 1pm EST, we will be hosting a public web chat to discuss auto-update mechanisms from the standpoint of balancing their security benefits with questions about appropriate disclosure and user control. Brad Arkin of Adobe will be participating, and the Google Chrome team has been invited to join, as well. The chat will incorporate VoIP audio (requires headset or microphone/speaker on your computer) as well as text, using dimdim’s Flash-based web conference system. Pre-registration is free and recommended. Just enter your e-mail address in the widget below. Feel free, as well, to help publicize this chat by clicking the “Share Widget” link.

When it comes to keeping client software patched against the latest known security vulnerabilities, automatic updates are one of the more effective mechanisms out there. By shifting the burden of checking regularly for updates from the user (we humans are notoriously unreliable) to the software, companies ensure that users at least are aware of the patches and, depending on the configuration, even get the patches installed automatically.

We’ve previously written about the problem of a software vendor abusing this system to push new software and/or potentially unwanted functionality to users’ computers. (See also the discussion here.) But, over at the blog of the Center for Education and Research in Information Assurance and Security (CERIAS), Gene Spafford writes about a different potential problem of automatic updates: they can break things. As Spafford writes:

The [Samsung BD-P]1500 [Blu-Ray player] came up with an on-screen message early in the week that a firmware update was available. Having had experience with downloads and upgrades of OS components, I waited a couple of days before doing anything. When I initiated the download, it completed without error, according to the display. However, after completion, it too was dead—no response to anything, including reset codes.

He goes on to relate Samsung’s response which, boiled down, was that they acknowledged the problem but didn’t know when there would be a fix available. In other words, installing the automatic update made his device unusable, and there was nothing he could do about it.

Thinking about the Apple Software Update fiasco, Spafford’s experience with his Blu-Ray player, and various past cases of updates causing some users’ systems to crash, I’m struck by the amount of power that a software or hardware vendor has when it incorporates an automatic update feature into its product. With little more than a single click by the user (or in the case of unattended updates, not even that), the vendor has the potential to disable a product, enable new functionality, push new products, and more.

Spider-Man’s uncle famously said, "With great power comes great responsibility." Indeed, any vendor incorporating automatic updates has a responsibility to use the feature in a way that benefits and protects the customer and does not abuse the customer’s trust. At a minimum, this includes sending updates only after extensive testing, protecting the system from abuse (e.g., someone coopting the system to distribute malware), quickly notifying users of and correcting "bad" updates, and avoiding the temptation to push new products or potentially unwanted functionality down users’ throats.

[Hat tip to Jon Kibler for bringing Spafford’s blog post to our attention.]