29.3. Windows XP Service Pack 2A Case StudyIn August of 2003, senior executives at Microsoft made it clear that continuing with a reactive patching approach to fixing security exploits was insufficient. Instead, users needed a system that was able to deal with whole classes of exploits and to prevent infection. The technologies required to achieve this required a major rewrite of several components of the operating system, and also required us to make changes to the default behaviors in Windows. While this last point may not sound like a big deal, this would be the first time in the history of Windows that a service pack release made significant changes to the user experience of the product. By working with the program managers for Service Pack 2, we presented evidence from user studies, surveys, instrumentation reports, and site visits to the Windows executives demonstrating that the release would not be successful without several large-scale changes to the user experience. This data had been collected primarily from research into Passport, Hailstorm, XP Service Pack 1, and early work on Windows Codename "Longhorn"the next version of Windows. It was fortuitous that it could be applied so directly to the problems that were addressed by XP Service Pack 2. We also worked to ensure that many of the changes could be controlled through group policy in order to satisfy corporate customers. Some of the major attack points in Windows are found in the Internet-related featuresInternet Explorer (IE), Outlook Express (OE), and the Application Execution Service (which prompts users to save or run downloaded or attached files). Various other system components, such as the Windows Firewall and Automatic Updates, are designed to help protect users but require user interaction in order to work correctly. The user experience focus for SP2 was on making security and privacy "just work," and where that was not possible, making the security and privacy issues understandable to users so that they can make informed decisions. To that end, we took several components of Windows and gave them a design overhaul. The following sections show before and after images with some commentary on the reasons for the changes. Most frequently, the reasons are based on the consent dialog redesign described earlier. 29.3.1. ActiveX DialogsIt was very clear from user testing that the ActiveX dialog box in Windows XP and XP Service Pack 1 (XP SP1) (see Figure 29-3) was not very successful at giving users the information they needed in order to make an informed consent decision. Figure 29-3. Original ActiveX consent dialogInstead of just applying the consent dialog redesign to this interface, we considered ways of also increasing user satisfaction. This dialog box typically appears while a page is loadingoften before any content has appeared on the first page of a site that a user visits. As such, it is both a frustration because it gets in the way of the user's primary task, and a dilemma because the user cannot judge the value of agreeing to the dialog box (if she even understands what it is asking). Taking a design element from Outlook Express, where additional information about email format options and blocked content is displayed in a "bar" in the message title area, we developed an in-context but discreet notification called the Information Bar, which animates down from the Internet Explorer Toolbar. The Information Bar (shown in Figure 29-4) provides the most condensed information possible to inform users in context that the web site they are on is requesting that they consent to a specific action. They can continue to browse the Web without responding to the Information Bar, or they can interact with the bar to enable downloads of files or ActiveX controls, or to enable blocked pop-ups. Figure 29-4. The Information Bar in Windows XP Service Pack 2For ActiveX controls, clicking the Information Bar produces the redesigned consent dialog shown in Figure 29-5. Figure 29-5. The updated Active X consent dialog; even if they read nothing else, users will see their options from the button labelsThe consent dialog from XP SP1 had contained a checkbox option to "Always trust" the given publisher, and thus not be pestered by these consent dialogs in the future. Once ActiveX controls got co-opted for unsavory uses, we observed users wanting a checkbox for "Never trust" more frequently than for "Always trust." After trying several iterations of these designs, we ended up with the "More options" button, shown in its expanded state in Figure 29-6. Figure 29-6. Expanded version of the redesigned ActiveX dialog; the options include a "never install" choice often requested by usersNote that the redesigned ActiveX consent dialog has several changes:
29.3.2. File Download DialogsFile download dialogs are mainly triggered by user actions in Internet Explorer. However, sometimes the user can be tricked into downloading software through a variety of code or social engineering manipulations. While XP SP2 removed several of the code exploits, it was still important to ensure that users knew what they were getting themselves into with file downloads, considering that the consequences could be catastrophic if the file were actually a virus. The file download dialog in Windows XP and XP SP1 (shown in Figure 29-7) was a relatively innocuous dialog that took an informative approach but did not really help the user. Figure 29-7. Original file download dialog; users have to read the entire dialog in order to see the questionNote the relatively useless text "You are downloading the file:", which takes precedence over the real question in the dialog"Would you like to open the file or save it to your computer?" This question is also misleading. In the case of a Word document download, you truly are "opening" the file. However, in the case of an executable program file, from a user perspective you are not so much opening the file as running it. Note also how the More Info button has as much precedence on the dialog as the much more important decision buttons. Applying some of the trust concepts described earlier, we arrive at the dialog shown in Figure 29-8. Figure 29-8. Redesigned file download dialog; the question is immediately apparent, and the additional information that users need for a trust decision is readily availableNote the purposeful similarities with the ActiveX control redesign:
Another problem with file downloads in previous Windows versions was that once the file was saved to the computer, it lost any identifying marks. Thus, a user could choose to download a file from the Internet, mindful of the risks, but then later open it on his machine without realizing its potentially dangerous history. The Application Execution Service (AES) is a part of Windows that most users never have to think about. Its job is to check that files are pretty much what they say they are, and then run them. In XP SP2, this little workhorse got some new functionality, and the issue then became how to message this functionality to users. The basic premise was that with the changes made in XP SP2, files that were downloaded from the Internet would be tagged as such, and would always retain that reduced level of "trustedness" until a user decided otherwise. This reduced trust carried with it a requirement that users explicitly consent to running the application. As such, the interface for the new Application Execution Service functionality became the consent dialog shown in Figure 29-9. Again, this dialog has purposeful similarities with the File Download control redesign:
|