XIX.5 September + October 2012
Page: 54
Digital Citation

Modeling is not the answer!

Susanne Bødker, Niels Mathiasen, Marianne Petersen

back to top 

In a 2008 CACM Viewpoints column, Susan Landau [1] calls for an understanding of the complexity of human behavior underlying IT security and proposes a multidimensional approach, with contributions from areas such as business, anthropology, and engineering. The reason for including these various fields is that the strong cryptology and secure protocols created by computer scientists have made hacking so difficult that hackers are now turning to users and the use situation to make their break-ins. Butler Lampson [2] is critical toward existing models and believes in better conceptual models of IT security, like Don Norman [3], who takes as his starting point how even security experts often work around security mechanisms. While both authors question the idea that we should strive for perfect, complete models of IT security, they argue that the conceptual model of security mechanisms that users have, or should be provided with, is the key to better security.

In HCI we have witnessed the rise and fall of conceptual modeling in general. The 1980s focused on changing human behavior, which was captured in models to inform designs. Around 1990 a second wave of HCI questioned the usefulness of this type of approach, pointing out how human behavior is contingent and situated, and that human beings actively work around whatever technical solutions exist. In more recent years, this has been supplemented with a focus on emotion and experience [4]. More than ever, this research points away from conceptual modeling.

Braz et al. [5] point out the common but false belief that security is related only to a software system's functionality, which can be designed independently of usability. We share this concern and are equally puzzled by the optimism surrounding conceptual models in the IT-security area represented by the authors mentioned here. It seems as if some within the usable IT security community have not embraced insights from past decades of HCI research, posing challenges to HCI as well as to IT security.

One of the very serious problems with models of security is they easily become complex. Models are static and users need to activate the entire complex model to achieve even simple things. These models stand in contrast to the contingencies of everyday life, in which human beings choose to use the lock(s) on their front doors to match trade-offs among the general risks of the area where they live and the inconveniences of locking, alarming, letting children in and out, and so on. This example shows that the perfect is the enemy of the good when it comes to IT security; we propose to take seriously how people handle such deliberations in everyday life.

In daily life, people rarely do activities solely for the purpose of security. Instead, most IT-security decisions are part of other activities with other purposes (e.g., signing up a child for day care at the municipal website). When analyzing these use situations, it is impossible to isolate IT-security tasks or decisions (such as typing a password or remembering to log out). Still, experiences from one activity influence the experience of dealing with IT security in another activity [4] (such as when a citizen later uses other municipal services). Accordingly, usable IT security cannot be studied without a view to learning and past experiences.

A longer story illustrates this point [6]: "Hans" tells this story:

"Some years ago my girlfriend went to Budapest with some of her fellow students. We planned for me to join her on an extended trip. The others had already booked their tickets online from some discount airline. These tickets were very cheap, but the price went up day by day. I had to act quickly and went ahead and bought the ticket. As you do with such payments, I supplied my credit card number, expiration date, and security number in addition to my full name, as demanded by airline security.

"As confirmation I received a stream of emails advertising other cheap tickets. Some days later, money had been drawn from my bank account. Days later again, the same amount was drawn again. First I felt irritated that the booking system didn't work; then I felt upset that I had to spend time correcting the mistake. I went to the airline's website and found that their only contact was through email. No street address or telephone number? I started to worry. Had I been fooled? Would I get my money back? Had I booked a real trip to Budapest? I wrote them a polite email. A few days later I received a very brief answer explaining that the airline's booking system was flawless! Even paying the double price, it was still an affordable vacation, so I decided not to bother. However, I still worried whether or not there was a flight at all. Some months later I had a nice and unproblematic trip to Budapest."

ins01.gif Participants engaged in the prompted exploration workshop.

In this example, Hans's trust in his friends, who ordered the original tickets, and the urgency of the situation caused him to ignore many aspects that he would otherwise be concerned with, for example, whether the Web-shop had a street address. In this way Hans did, indeed, demonstrate insecure behavior, even though his interaction with the "flawless" website as such was sufficiently secure. None of this prevented or remedied the double payment, however. Hans's calmness along the way was mainly due to the low price of the ticket.

Traditionally, the aim of usable security has been to encourage, enforce, or help people act securely. However, the story here illustrates that not only should IT artifacts and data be securely handled but also that the use situation as such contains many secure and insecure elements that need to be understood and addressed together. Finally, the fact that it all ended well may have led Hans to retell the story differently than if his worst fears had come true. The story shows how users draw on previous experience when they make sense of IT security and how IT security is contingent and situated. This is a challenge to studies of IT security.

From a design perspective, it is difficult to discover and get access to such real-life, situated experiences. Users themselves may not know which experiences they make use of, and it is challenging to find ways of prompting people for relevant experiences from their past. In the IT-security domain, situations in which security is critical are infrequent and unpredictable, and hence it is challenging to assess the technological design in use-like settings. Putting people in situations in which they perceive the same threats and risks as they would in real situations may be unethical or even dangerous.

In the IT Security for Citizens project, we have investigated what other means designers might have for achieving usable security in design and use, with the primary goal of designing a mobile, usable, and more secure digital identification for everyday use (e.g., for online payment; further details in [6,7,8]). In the following we briefly present examples of such methods as inspiration for designers involved with usable IT security beyond modeling.

back to top  Understanding Situated Security Experiences from User Stories

Purpose: To get richer access to real-life, situated IT-security experiences, we engaged a number of people in reporting on their security experiences as they happened or whenever they had anything to tell, whether good or bad: successes, failures, frustrations, strategies they used or were requested to use, and so on.

Example: Over a period of five weeks, we asked 10 people to describe their IT-security experiences using the communication channel best suited at the time. This included text messages (SMS), picture messages (MMS), text, pictures or video clips in email, a voicemail answering service, as well as notes sent by surface mail. It was important that the users' efforts and the time gap from observation to report were minimal so as to capture the unfolding experience. We received a total of 40 descriptions.

Examples of these stories illustrate the situated nature of security:

"...I used home banking to do a payment. Every time I do such a task I have this insecure feeling that I mistyped some digits..."

"...I went to a toy store to buy a game and paid with a credit card. The sales clerk told me to use the chip on my credit card, but to sign a slip instead of typing my PIN code. I swept my card through the normal machine! First I was worried. I mean, it should be the same in any store, but the store belongs to a big chain and it did not seem to matter if my payment was enabled by a knuckle buster or not."

These narratives were used as a basis for interviews, workshops, and scenarios in our design process.

Potential: First of all, we learned that these stories about security experiences give designers access to real security issues. Users may need to be probed more about what happened (e.g., in later interviews), but the stories helped this prompting.

back to top  Triggering Experiences Through Prompted Exploration

Purpose: Prompted exploration workshops were developed to engage future users in the design process based on their actual experiences of IT security. By prompting the discussions through a number of inspiration cards (e.g., [9]), the aim was to make people share stories about their experiences with signing and paying, whether online or not. The idea of the themes on the inspiration cards was to clarify and somewhat overstate previous research findings on usable IT security, hence probing and provoking users' past experiences and current assumptions.

Example: Users and designers worked together through brainstorming, design discussions, and sketching possible design solutions based on scenarios (from the User Stories collection) in order to design a mobile digital identification.

The participants were prompted by inspiration cards with the following themes: implicit security, security negotiation, social navigation, motivated security, tangible security, proportional security, and feeling secure (see sidebar).

A workshop lasted three hours. A designer introduced the IT-security domain, the six discussion themes, and examples from possibilities, and challenged underlying assumptions of the participants. The themes were handed to participants and the design task was introduced. The participants worked in groups of three or four. At the end, each group presented their work to the rest.

Potential: It took a fair amount of work to actively use the themes in the group discussions, whereas the design exercises as such prompted the participants to think about usable security. Participants may need a better introduction to the discussion themes to help with discussion and inspiration.

back to top  Making Security Tangible Through Acting Out Security

Purpose: To supplement the user stories and workshops and support participants in acting out security in everyday situations in a real context, we prototyped a mobile phone identification and a point-of-sales application for a cafe.

Example: Normally, guests pay at a cafe using cash or credit cards. By installing our application on their mobile phones, they were able to use their mobile phones and mobile digital identity. In this case, users' prior experiences included some of these forms of payment, as well as their cellphone security practices.

The enactment took place during normal opening hours at the cafe, when other customers were present. A tablet PC worked as point-of-sales software in parallel with the cafe's normal cash register. The application made it possible to pay for beverages and snacks using a cellphone to sign for a purchase, either on the participants' own cellphones or on a borrowed one. All participants made several transactions during the three-hour session.

The participants were prompted to sign for payment of the beverages and snacks they ordered. In this they made use of a combination of their experiences with other payments forms, other cafe visits, and their experiences with previous transactions in the enactment. We even got access to quite advanced security behavior through only a few hours of transactions, as illustrated by the following story.

A friend of one of the participants came into the cafe. The participant offered her friend a cup of coffee and lent her phone to her friend. She whispered the PIN code in her ear and the friend ordered a cup of coffee. The bartender served the coffee, selected coffee on the tablet PC, and asked the "new participant" to sign without further comments, which she did. From the debriefing we understood that the participants and their friends sometimes borrowed credit cards and PIN codes from each other, even though banks do not approve of this practice. This behavior clearly inspired the phone signing observed in acting out security. This approach clearly contradicted the assumptions of the designers and had strong implications for continued design.

Potential: The devil is in the details when it comes to understanding people's IT-security practices as they unfold. This kind of detailed enactment takes a significant effort to set up, at the same time as it makes it possible to get beyond immediate assumptions.

We hope we have provided some ideas about how to design for usable security without falling into the trap of better generic modeling. We invite readers to peruse the referenced articles and explore the methods themselves.

back to top  Acknowledgements

The work presented here is based on Niels Mathiasen's Ph.D. thesis and the three referenced papers by the authors.

back to top  References

1. Landau, S. Privacy and Security. A multidimensional problem. CACM 51, 11 (2008), 25–26.

2. Lampson, B. Privacy and Security. Usable security: How to get it. CACM 52, 11 (2009), 25–27.

3. Norman, D. The Way I See It. When security gets in the way. interactions 16, 6 (2009), 60–63.

4. McCarthy, J. and Wright P. Technology as Experience. MIT Press, Cambridge, MA, 2004.

5. Braz, C., Seffah, A., and M'Raihi, D. Designing a trade-off between usability and security: A metrics-based model. In INTERACT 2007, LNCS 4663, Part II, C. Baranauskas et al., eds. 2007, 114–126.

6. Mathiasen, N. and Bødker, S. Threats or threads From usable security to secure experience? Proc. NordiCHI 2008, 283–290.

7. Mathiasen, N. and Bødker, S. Experiencing security in interaction design. Proc. CHI 2011 2325–2334.

8. Mathiasen, N., Bødker, S., and Petersen M.G. While working around security. Proc. 3rd International Conference on Human Computer Interaction, IndiaCHI 2011.

9. Halskov, K. and Dalsgaard, P. The emergence of ideas: The interplay between sources of inspiration and emerging design concepts. CoDesign: International Journal of CoCreation in Design and the Arts 3, 4 (2007), 185–211.

back to top  Authors

Susanne Bødker is a professor of human-computer interaction in the Department of Computer Science, Aarhus University. She is known for her work on computer-mediated human activity.

Niels Raabjerg Mathiasen is a software developer and consultant at Trifork designing and developing IT solutions. He specializes in design of IT-security-sensitive artifacts and user involvement. Recently, he defended his Ph.D. on the topic of HCI and security in the Department of Computer Science, Aarhus University.

Marianne Graves Petersen is an associate professor of human-computer interaction in the Department of Computer Science, Aarhus University. She conducts research into interaction design for pervasive computing.

back to top  Sidebar: Example Discussion Themes

Tangible Security. As human beings, we trust tangible things. If we have our car keys in our pocket, it is less likely that someone else is using our car. If we firmly push down a door handle and the door does not open, it is locked. But things like passwords and key-stores are not as tangible. Can IT security be tangible?

Proportional Security. "Take not a musket to kill a butterfly." This happens in IT security. Front doors are normally locked with a rather sophisticated lock that keeps strangers out, while restroom doors have simple locks, the main purpose of which are to tell other people that the restroom is occupied. Strong and complex security is often required to accomplish even simple tasks when it comes to IT. Are there simpler means?

back to top 

©2012 ACM  1072-5220/12/0900  $15.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2012 ACM, Inc.

Post Comment

No Comments Found