The principle recurring problem in user experience is creating a user interface that supports the user’s mental model of how an app works, while simultaneously enabling the actions that are actually supported by the implementation’s model of the problem domain. Make the interface too much like the app internals, and the user won’t be able to make it fit their view of how things work.
A useful technique in this field is to present the user with a metaphor, to say “the thing you’re using now is a bit like this thing you’ve used before”. That worked much better in the old days when computers were new and people actually had used those things before. Now, metaphors like address books, landline handsets and envelopes are getting tired, and a generation of people have grown up without using the things these metaphors are based on.
So how do security metaphors stack up? Well, here the situation is even worse. In these situations even though people do use the real-world devices, the metaphors are strained beyond the point of usefulness.
Locks and Keys
You’d be hard pushed to find a security vendor or industry blog that doesn’t include a picture of a padlock on it somewhere. There, mine does too! A lock, using a particular mental model, is something that keeps you from using the door to a place or container (or keeps you in and other people out). The key permits you to act almost as if the lock weren’t there when you want, and almost as if the door didn’t exist (i.e. that the wall is solid) when you want.
There are few places in security UIs where locks exist (ignoring Keychain, which is already a response to a security/usability fail in itself), but plenty of keys. Keys that don’t interact with locks, but instead turn readable messages into unreadable messages. In the real world, that is (or was) done by an envelope, or by choosing carefully who you tell your message to.
Keys in software can be magically created from passwords. So hang on, does this door need a password or a key to get through?
Keys in software can validate the integrity of data, showing that it cannot have changed since the keyholder saw it. How does that map onto real world keys? Oh, and we call this a signature. You know, exactly unlike how you sign your name.
Finally, there are some types of key that you can give to anyone, called public keys. These can be used to lock things but not unlock them. WTF?
Certificates
While we’re talking about keys, we should remember that they can be stored on keychains, keyrings or certificates. Wait, what?
In the real world, certificates that I own tell me that I am a motorcycle’s registered keeper, that I have completed a variety of different academic and training courses, and related information. The certificate is usually issued by the body that’s best placed to assert the truthiness of the certified statement: the DVLA, the academic institution and so on.
A digital certificate is more like a notary statement of identity than any of those certificates. Except that, far from being issued by a notary, it’s issued by anybody. Some certificates are issued by organisations who pay attention to other people’s notary statements about the holder’s identity. Sometimes, those certificates tell you (though not in plain language, of course) about how seriously they checked the identity of the holder.
How do you find out the identity of the organisation that issued the certificate? Why, with another certificate, of course! Imagine that my degree certificate was stapled to a certificate saying that the signer worked at the tutorial office, which was stapled to another saying that the tutorial office was part of the administration department, was stapled to…
So we need better metaphors?
No, we need to acknowledge that most security behaviour is internal to the software system that’s being secured, and keep it out of the user interface. A field worker in sales thinks “I’ve got an e-mail from my boss, I’ll read that”, so let her read that. Do the signature/certificate stuff internally. If that e-mail turns out not to be from her boss then rather than showing the certificate, don’t let her think that it is from the certificate.
No UI is good UI, right?
Here’s the security UI Apple added to Mac OS X in Lion.
So if Apple is no longer putting security user interface in their product, that must make it the universally blessed approach, right?
Not so fast! One limitation of many security systems is that they do rely on some user involvement. It’d be great to make it all entirely invisible, but some of that user involvement is necessary: software is used in an environment that is only partially technological, but is partially social. Requirements for things like confidentiality and integrity that are born of meatspace needs still must be supported by user involvement.
And that’s where we meet another problem. If we completely remove security UI from our products, we lose any chance to remind people that they too have skin in this game. Where data is confidential, if it doesn’t look confidential it doesn’t switch the reader into “remember to keep this secret” mode. Switching the software into that mode is almost trivial in comparison.
As an example, both Mac OS X and iOS have shipped forever without a user password and without requiring the user to set a password. Great, no security UI. But do the people using Macs and iPhones understand the difference in security posture—particularly on iOS with data protection—implied by setting a password? It doesn’t fit into the password metaphor, where a password just lets me in and doesn’t do anything about encryption.
Conclusion
There are two problems when it comes to security UI. Traditional UI in this arena exposes too many details of the software internals, and relies on flakey metaphors that do not translate either to the user’s mental model nor the software’s implementation model of the security feature. On the other hand, if we just remove this UI then users aren’t reminded of their part in the security of the overall, socio-technical system.
Thankfully solving these problems is not mutually exclusive. By communicating with users on their own terms at relevant times, an application’s interface can encourage users to take part in the overall security of the system without either confusing them or turning them off of engaging by using overly technical language and concepts.
