Section 17.2. Chameleon User Interface

17.2. Chameleon User Interface

This section describes the current version of the Chameleon interface and highlights issues we considered in its design that are specific to security interfaces.

Security as a secondary (or tertiary, or lower-priority) task means not only that the security operations must be easy to use, but also that they cannot interfere too much with the primary task or tasks. We designed the Chameleon interface to be easy to use itself, and also to not intrude on the ordinary activities that people want to perform.

To make Chameleon easy to understand and use, we used popular interfaces such as Microsoft Windows and the Macintosh as a starting point. Chameleon uses separate, overlapping windows to display applications and to browse and manage files. The Chameleon design attempts to add or modify this interface style only as much as necessary to support roles. The role features are designed to be simple, so they are easy to understand and convenient to use. Chameleon has evolved over time through two low-fidelity (paper) prototypes and one software prototype, based on lessons learned in user studies. These old versions of the interface are shown in Figures 17-1 and 17-2.

The current implementation is under development; a schematic of how its screen will be laid out is shown in Figure 17-3.

WHY LOW-FIDELITY PROTOTYPING?

In developing Chameleon, we used a technique called low-fidelity prototyping (or low-fi prototyping for short). In general, prototyping is invaluable in many design activities, and user interface design is no exception. Prototyping allows designers to gather feedback early, consider many alternatives, and keep design centered on the user.

Low-fi prototyping usually involves tools like paper-and-pen media that are unstructured and easy to work with. In contrast, typical high-fidelity prototyping uses animation or software tools such as Macromedia Flash or Director, or Visual Basic.

Low-fi prototyping has several advantages over high-fi prototyping. Because it is created with simple, natural media, it is faster and easier to create the prototypes.^[a] Even the most advanced software tools for building animations or graphical user interfaces require much more time than paper, pen, scissors, and tape to create simple interfaces.

Low-fi prototyping can also be used much earlier in the design process. Earlier evaluation and feedback about designs is valuable because it allows designers to compare design ideas before a lot of time and energy have been invested.

An advantage of low-fi prototyping that may be surprising is its ability to elicit better early-stage feedback about the interface than high-fi prototypes. When presented with high-fi prototypes, people get the impression that the design is finished and their comments tend to focus on details, such as font sizes or alignment of widgets. In the early stages of design, though, what is really valuable is high-level comments about the interface, such as whether it's on the right track at all. Low-fi prototypes look much less finished, so people are more willing to be critical, which is exactly what designers need.

^[a] Marc Rettig, "Prototyping for tiny fingers," Communications of the ACM, 37:4 (April 1994), 2127.

If you design user interfaces or web sites, low-fi prototyping can be a very useful tool. If you'd like to learn more, consult the books devoted to low-fi prototyping.^[10]

^[10] Carolyn Snyder, Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces (Morgan Kaufman, 2003).

Users need to be aware of what role each program and file belong to. Otherwise, a user might put an untrustworthy application, such as a game downloaded from an untrusted web site, in the same role as valuable data, such as personal financial records. To make roles visible, all windows and icons in Chameleon have a colored border that shows what role they belong to. Windows also have the role name in their titlebar. As an extra cue indicating what role the user is currently working with, all windows that do not belong to

Figure 17-1. Low-fidelity prototype

Figure 17-2. Visual Basic prototype

the currently active role are dimmed slightly. We plan to study whether this level of notification will give users a sufficient level of role awareness.

Figure 17-3. Schematic of the Chameleon X Windows implementation; cross-hatched regions are controlled by trusted software; gradient areas are controlled by end-user applications; application borders indicate their role

Of course, in addition to being aware of roles, users also need to interact with roles. Specifically, Chameleon supports these role-based actions:

• Copying and moving files across roles

• Specifying the role in which to start an application

• Specifying the role(s) in which to install an application

Based on user testing, the current design provides the following methods for these actions.

Because the role to which a file belongs is tied to what directory it is in, the user can copy and move files across roles, just like copying and moving files within a role, simply by dragging and dropping the file from a folder that belongs to one role to a folder that belongs to another. A file can also be copied or cut to the clipboard in one role, and pasted into another.

Sometimes, a user may want to access a file that belongs to role A from an application that belongs to role B. For example, the email application running in the Communications role might want to attach a file from the Vault role. The user could copy the file to the Communications role, but this would be cumbersome. An easier way is to use a file dialog box that has been enhanced to know about roles, as shown in Figure 17-4.

An important issue with the design of security interactions in Chameleon is how easy they should be. Security in Chameleon comes from role separation. So if, for example, moving or copying files across roles is too easy, people might do it too readily, without considering the security implications. Although this is a risk, Chameleon errs on the side of convenience because experience with other security technologies shows that people are very willing to work around mechanisms they deem too inconvenient. Even if users move or copy some files across roles in a way that exposes them, that is better than abandoning Chameleon altogether and losing its benefits for all their other files, too.

Figure 17-4. Role-aware file dialog box from low-fidelity prototype; the role palette on the left side chooses the role to browse; the "Roles" button hides and shows the role palette

The decision to require all files in the same directory to belong to the same role seemed simple, straightforward, and easy to understand and use. Then we considered the desktop, where it is likely that people will want to put files and applications from different roles side by side. Showing all files from all roles at the same time could make for a messy desktop. But showing only files that belong to the currently active role could be confusing, and would require users to remember what role a file belonged to.

Applications, too, can be installed in multiple rolesfor example, a simple text editor might be useful in many roles. As with files, we considered a verbose and a concise option for displaying desktop icons for an application installed in multiple roles. The verbose option is to show a separate icon for each role in which the application could run. The concise option is to show only a single icon but to change the color of its border depending on the role of the active window. If the application is available in the active role, we would color its icon border to match; otherwise, we would color it gray to indicate that it is not available in that role.

Our user studies so far indicate that people have strong preferences about which display style to use for iconsstrong, but different, preferences, unfortunately. There is a slight preference for separate icons for files and applications, so that is the default. Given that nearly half of people prefer the other, it should be easy to change.

The next section describes the interface development process, and issues that we discovered from user testing and analysis.

SURFACE SIMPLICITY, HIDDEN COMPLEXITY

In Chameleon, applications are limited to accessing only files in their role. However, this sometimes conflicts with user desires, for example, to attach to an email message a file from a different role. Chameleon solves this problem by enhancing the traditional file dialog box (see Figure 17-4). This decision illustrates how simple decisions in the interface may entail adding complexity "under the hood."

The reason this simple interface complicates the underlying system is that allowing applications access to files belonging to other roleseven to browse the directories and see what files are thereviolates the security model that is crucial to the security Chameleon provides. The problem is how to allow users to do the simple, obvious, intuitive thing of opening a file in another role without introducing a security vulnerability by violating the security model.

For interface consistency and ease of programming, most applications use the file dialog that the system provides, and run the same code from the same shared library. However, this dialog box is created and controlled by the application, with the rights and permissions of whatever application made it. In Chameleon, if the dialog box has the same rights as the application, it can't access other roles' files.

The solution Chameleon uses is to change who owns the file dialog box. The Chameleon file dialog box is not controlled by the application, but by the system, and so has the ability to look at other files and directories. What this dialog box passes back to the application is a name that provides access only to the file specified by the user in the dialog. This access is OK because it is specified explicitly by the user.