Capability User Interface

What should the UserInterface look like in a system that follows a CapabilitySecurityModel?

This paper gives a partial answer:

[Ka-Ping Yee, "User Interaction Design for Secure Systems", http://www.sims.berkeley.edu/~ping/sid/]

Here's the current list of ten suggested principles for secure interaction design.

Path of Least Resistance. The most natural way to do any task should also be the most secure way.

Appropriate Boundaries. The interface should expose, and the system should enforce, distinctions between objects and between actions along boundaries that matter to the user.

Explicit Authorization. A user's authorities must only be provided to other actors as a result of an explicit user action that is understood to imply granting.

Visibility. The interface should allow the user to easily review any active actors and authority relationships that would affect security-relevant decisions.

[Reply by unknown author:] This is a design issue and shouldn't practically affect the actual security provided (if the security is any good). Showing inaccessible but otherwise possible UI elements has certain advantages: a) it povides the opportunity to inform the user of WHY they cannot perform the action; it indirectly informs the user that the capability IS possible, as opposed to missing or malfunctioning.

[Reply by Ka-Ping Yee:] Dismissing this as "a design issue" doesn't make sense to me, since design of the user interface is exactly the issue being addressed here. The point is that if users can't predict the security consequences of their actions, they will have a much harder time trying to use software securely.

Was the comment by the unknown author supposed to be directed at "Expected Ability"? It makes a little more sense that way, although I would still disagree with the comment. -- DavidSarahHopwood

Revocability. The interface should allow the user to easily revoke authorities that the user has granted, wherever revocation is possible.

Expected Ability. The interface must not give the user the impression that it is possible to do something that cannot actually be done.

Trusted Path. The interface must provide an unspoofable and faithful communication channel between the user and any entity trusted to manipulate authorities on the user's behalf.

Identifiability. The interface should enforce that distinct objects and distinct actions have unspoofably identifiable and distinguishable representations.

[Reply by unknown author:] This is categorically impossible. Yes, a system can verify that two agents are distinct through cryptography. But no, it's not possible to convey this information to a human being. This is because there's no way to simplify this almost completely useless information to make it easy or natural to convey. And human beings are incapable of keeping track of vast amounts of very abstract and transitory information.

[Reply by Ka-Ping Yee:] It's certainly possible to show a human being that two objects are distinct. You can label them with different names or display them with different icons, for example. Desktop GUIs do this by letting you name and rename your files and preventing you from assigning the same name to two files.

Expressiveness. The interface should provide enough expressive power (a) to describe a safe security policy without undue difficulty; and (b) to allow users to express security policies in terms that fit their goals.

Clarity. The effect of any security-relevant action must be clearly apparent to the user before the action is taken.

For a detailed explanation of the thinking behind these principles and applications of these principles to real software, please read the paper.

In general, a capability-secure UI will look very much like conventional UIs (following principles like DirectManipulation, etc.) - except that it will have fewer "security dialogs". Since authority is not separated from designation in a capability system, the operation of designating some object to work on (e.g. in a file chooser), will also authorize access to it, and so no separate security dialog is needed.

Also see this paper on the EROS Trusted Window System: <http://srl.cs.jhu.edu/pubs/SRL2003-05.pdf>.

A good place to discuss this is the e-lang mailing list (http://www.eros-os.org/mailman/listinfo/e-lang).

Both graphical and command-line interfaces are important. Here is a thread about GUIs on e-lang:

"Pola and GUI operations" http://www.eros-os.org/pipermail/e-lang/2002-December/thread.html

and here is one about command shells:

"Questions on protection provided by capabilities" http://www.eros-os.org/pipermail/e-lang/2003-September/thread.html

CategorySecurity CategoryUserInterface