Lessons from the auto-update web chat

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.