Nielsen Norman Group and Northwestern University | norman@nngroup.com
November + December 2009
interactions
I recently attended two conferences on usability, security, and privacy. The first, SOUPS (Symposium on Usable Privacy and Security), was held on the Google campus in Mountain View, CA, the second at the National Academies building in Washington, DC. Google is a semi-restricted campus. People can freely wander about the campus, but most buildings are locked and accessible only with the proper badge. Security guards were visible, polite, and helpful, but always watching. Our meetings were held in a public auditorium that did not require authorization for entrance. But the room was in a secure building, and the toilets were within the secure space. How did the world’s security experts handle the situation? The side door of the auditorium that led to the secure part of the building and the toilets was propped open with a brick. So much for key access, badges, and security guards.
Both conferences were attended by experts in usability, security, and privacy. Both conferences emphasized that if we ever are to have systems with adequate security and privacy that people are willing to use, then the three fields must work together as a team. Without usable systems, the security and privacy simply disappear as people defeat the processes in order to get their work done. My experience at Google illustrates the point.
The numerous incidents of defeating security measures prompts my cynical slogan: The more secure you make something, the less secure it becomes. Why? Because when security gets in the way, sensible, well-meaning, dedicated people develop hacks and workarounds to defeat it. Hence the prevalence of doors propped open by bricks and wastebaskets; passwords pasted on the fronts of monitors or hidden under the keyboard or in the drawer; house keys under the door mat, above the door frame, or under fake rocks that can be purchased for this purpose.
We are getting a mixed message. On the one hand, we are continually forced to use arbitrary security procedures. On the other hand, even the professionals ignore many of them. How is the ordinary person to know which ones matter and which don’t? The confusion has unexpected negative side effects. I once discovered a computer system that was missing essential security patches. When I questioned the computer’s user, I discovered that the continual warning against clicking on links or agreeing to requests from pop-up windows had been too effective. This user was so frightened of unwittingly agreeing to install all those nasty things from “out there” that he denied all requests, even the ones for essential security patches. On reflection, this is sensible behavior: It is very difficult to distinguish the
legitimate from the illegitimate. Even experts slip up, as the confessions reported occasionally in various computer digests attest.
The situation with security is similar to the situation once faced by the human-centered design community. In the early days of software development, programmers and engineers devised the systems, sometimes giving in to feature lists from the marketing community. After they had finished, they would ask the usability and technical-writing communities to make it usable and understandable (and the designers to make it pretty). It is only when practices change to enable all of these groups to work as team members from the project’s start that improvements occur. So too with security and privacy, except in this case, the security and privacy processionals are the outcasts. It is time to make them first-class citizens who work with the product team throughout the entire development cycle to produce cohesive systems that are understandable and usable, functional and safe, secure and private.
If this endeavor is to be successful, we need more understanding of the issues; better tool kits to deliver to developers; and a comprehensive set of tools, scripts, and templates for the administrative support staffs around the world so that the rules and polices they develop will be consistent both with one another and with the best prac-
References:
Archives