Section 29.3. Windows XP Service Pack 2A Case Study

29.3. Windows XP Service Pack 2A Case Study

In 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 Dialogs

It 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 dialog

Instead 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 2

For 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 labels

The 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 users

Note that the redesigned ActiveX consent dialog has several changes:

Button defaults. Buttons have a secure default: clicking Enter chooses the Don't Install option.
Button labels. Button labels change from OK and Cancel to Install and Don't Install. Users can now see the implication of clicking the button (something will be installed) without reading any other text on the dialog.
Primary text. Primary text on the screen is a simple question. In the previous design, it wasn't even clear to most users that there was any question at all in the text.
Evidence. "Evidence" that the computer knows to be true (via certificates) is presented to the user. Clicking on the items allows experienced users to see certificate details and the originating site. This helps prevent users from being fooled into clicking on a consent dialog that appears to be from the site they are on but that was actually produced by a pop-under advertisement (trust by association).
Assistance text. Assistance text is shown in a separate area at the bottom of the screen, with a link to further assistance. This is useful if this is the first time a user has seen this dialog or if the user sees such dialogs infrequently. However, the text is out of the way if the user knows what he is doing.

29.3.2. File Download Dialogs

File 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 question

Note 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 available

Note the purposeful similarities with the ActiveX control redesign:

Button defaults: Buttons have a secure default; clicking Enter chooses the Cancel option.
Button labels: Button labels are more accurate descriptions of the accompanying actions. In the previous version, users were invited to "open" an executable file in the same way that they might "open" a text file. Changing the terminology for executable files is one extra clue to users about the nature of the downloaded file.
Primary text: Primary text on the screen is a simple question. Also, making the question into the primary text reduced its length, as there was no need to refer back to the previous statement in the dialog.
Evidence: "Evidence" that the computer can ascertain is presented to the user. The user can see the originating site, check that the filename matches his expectations, and also check that the size of the file seems appropriate for the type of application he expected.
Assistance text: Assistance text is shown in a separate area at the bottom of the screen, with a link to further assistance. This link replaces the large and distracting More Info button.

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:

Button defaults. Buttons have a secure default; clicking Enter chooses the Cancel option.
Primary text. Primary text on the screen is a simple question. While it may seem to be an overly obvious question (after all, the user just double-clicked on an icon), often executable files masquerade as documents for just this reason. In these situations, the AES recognizes the subterfuge and presents the consent dialog, thus alerting the user to the true nature of the file.

Figure 29-9. The Application Execution Service consent dialog; this dialog takes over from the file download dialog if users choose to save rather than run a downloaded file
Evidence. "Evidence" that the computer can ascertain is presented to the user. The user can see the software publisher and check that the filename matches his expectations.
Checkbox. There is a "don't show me this again" checkbox on the dialog, but it is purposefully phrased as a positive statement.
Assistance text. Assistance text is shown in a separate link at the bottom of the screen, with a link to further assistance. This dialog is new, and most users will see it infrequently, so the assistance text is available but not in the way of the primary decision.