Testing for Usable Security - What Relationship, If Any, Does It Have To Product Design?
July 24, 2008 by Richard ConlanPanel Moderator: Mary Ellen Zurko, IBM
Panelists:
* Stuart Schechter, Microsoft
* Phil Hallam-Baker, Verisign
* Jon Callas, PGP
* Tyler Close, HP
The panel started by pointing to Usability Evaluation Considered Harmful, which claims:
- a combination of methods triangulates and enriches discussion of a system’s validity
- evaluation done too early can kill promising ideas
- evaluation ignores cultural adoption and use
Is usable security different?
Do products with features whose job it is to provide protection against maliciousness fare any differently?
Where are the appropriate ways to validate one’s work when the work is usable security?
When the goal is something other than published research, such as products or standards, how do the validation methods change?
Stuart Schechter, Microsoft
Position
Security assumptions that rest on user behavior must be scientifically tested.
Evaluations must not underestimate the adversary.
Usability problems are often the result of failures in the architecture or ecosystem built around a product.
He used Code Signing as an example. While the Publisher is verified in the signed certificate, the Publisher is free to set the Product Name for the confirmation dialog to whatever they want. Microsoft’s security assumptions in code signing were that users will avoid Products from Publishers they don’t trust. This could have easily been tested to determine whether users were more swayed by the Publisher name or the Product name.
If the claim is something is not testable then there is implicit risk of mis-assumption. If the known best is known to be poor then it could be worth taking the risk, but there is a solid risk.
Jon Callas, PGP
Position:
Designers know best.
Testing has its place. It can tell you what color the buttons need to be, where to put them, and reveal user preferences. Testing can reveal bugs. It can kill bad ideas. But, it cannot tell you what to do right.
Testing can impede progress. Every user in the world knows that change is bad. People like what they are used to. They forget how much they hated what they have now (e.g. initial complaints upon the original release of the current version).
If training is required and something is truly new then testing will generally show that it sux. Usable security requires change. Design is an art form. And like in art, “plot selected by focus group” does not bode well.
Sometimes when somebody has an idea that does indeed test well, you still need to be willing to say no. This is especially true in security. HCISec is hard. But, we’re designers for a reason. Any coherent vision is better than no vision at all. Testing can help refine coherency and can point out gross deficiencies.
But don’t forget - everything we love now once sucked.
Phil Hallam-Baker, Verisign
Position:
The situation regarding Internet crime is bad. We don’t have to evaluate the products available for protecting us from Internet crime - they all suck. The situation may be bad, but experiments are making them worse.
Lab studies measure the wrong thing. They don’t tell you how the user will use the product in practice - they’ll just be confused by the novel UI or whatever and all you discover is that users are confused by new things. The mere fact that there is a discipline based around experiments does not mean those experiments are useful.
Scientists explore the world as it is. Engineers want to change it. Engineers require a map. The map we have established from all our experiments is effectively a swath of Here There Be Dragons. Cathedrals were built by trial - if it collapsed, it wasn’t a good design. It was possible to build solid cathedrals by the 1400s - even though we couldn’t scientifically demonstrate the safety or concepts until the 1800s.
Design Law #0: If its not safe, its not usable.
“We can’t make it more secure because the user won’t understand it. It won’t be usable.” Wrong. If it isn’t safe, it isn’t usable.
Design Law #1: If the user cannot distinguish an unsafe action from a safe one, it is unsafe.
Tyler Close, HP
Position:
“Considered harmful” is a famous phrase in CS coined by Dijkstra. This is effectively a usable security argument - the user can only internalize so much context.
What might Dijkstra say about usable security were he here today?
Dijkstra worked out from first principles the cognitive load necessary to handle the goto statement and determined that it must go away, even though he didn’t yet know how to replace it.
Correspondingly, experts should perhaps design development tools such that they can more easily create more usable software in the normal flow of development. Won’t work you say? But it has - in programming language design. Is usability all that different?
Look at JavaScript - the programmers have a lack of understanding of the underlying syntax and execution model…but it doesn’t matter! If only they could similarly make usable UI without having to understand the underlying model. Dijkstra might buy this, but could well claim that UIs are just different. The history of programming languages is a forward march of enabling the programming to express his/her intent.
The design of a good programming language is at least as hard as the design of a good UI.
The way forward is expert review of the tools programmers use. What sorts of changes might this entail? The OK button is an awful lot like the goto statement. The application is basically asking the user to take responsibility of the whatever happens next. What would happen if we removed the control-flow construct of prompting the user in this way? Sound painful? Well, that’s what some said about goto.