Privacy Control for Location-Enhanced IM

Justin Goshi, Evan Welbourne
{goshi, evan}@cs.washington.edu

Motivation

   A critical analysis of privacy control systems for ubiquitous and location-aware computing reveals a number of usability problems.  Recent work (most notably the Houdini/Vortex project at Bell Labs, and work with "Faces" at Berkeley) suffers the same flaws as traditional preference systems (e.g. users don't accurately set and manage their privacy preferences - if they change the default settings at all).  Thus, a central obstacle for privacy-observant location systems remains in the difficulty of getting users to fluently understand and precisely control their privacy settings.  In this project, we explore potential strategies for overcoming this problem in the context of a specific application: a location-enhanced instant messenger (IM).  In particular, we look at privacy control for a location-enhanced IM that supports queries on a buddy's instantaneous location, queries on location history, and a "reverse finger" option that shows the rate at which a buddy has been querying "my" location.

Methodology

   Our approach was to conduct a formative prototyping and evaluation study consisting of one survey, two iterations of low-fidelity prototypes, and one set of semi-structured interviews.

   The survey was designed to gather a general understanding of the potential user population (CSE students and faculty) and its location privacy concerns - consisting of a few background questions (e.g. "Do you use IM?  SMS?") and about 15 questions that ask the participant to rate his or her concern (on a Likert scale) for varying types of location disclosure (fuzzed, exact, history) and inquirer (buddy, CSE person, stranger).  The responses of the 29 survey participants, together with a quick paper prototyping study informed the design of the second lo-fi privacy control prototype - in particular, it led to the "linearization" of the privacy disclosure space as it appears in the 'privacy slider' (i.e. none, fuzzed, exact, history).

   We then carried the second prototype (done in HTML with JavaScript) into the second user study - the semi-structured interviews.  Each interview was conducted with one participant, one facilitator, and one observer in two stages: an informal discussion of the person's privacy concerns (both to study existing user concerns and to study user understanding of the potential threats), and a task-driven session with the lo-fi prototype (designed to study how our interface affects, enhances, and reflects a user's concerns and understanding of the system's disclosure capabilities).  We interviewed 6 participants (2 female, 4 male), and used the results to reach our main conclusions and to guide future design efforts.


Conclusions

   As a result of this project, we have a working location IM server, an HTML/JavaScript client with privacy controls, and a substantial amount of information - both on CSE-users' location-privacy concerns and on their responses to our privacy control mechanisms.
   The people we interviewed generally felt that our location enhanced IM application would be more useful in the workplace than in "daily personal life". This is mainly because people in the workplace commonly look for their colleagues by walking over to their office. Outside of the workplace people commonly use cell phones, which they are familiar and happy with, and would probably not consider replacing.
   Whenever possible, it is best to support (and not alter) existing social patterns with respect to privacy. We learned this as a result of our discussions on the "reverse finger" control - the participants didn't always want their buddies to know when he or she is looking for them.  This is consistent with existing social patterns, for example, if we think about the workplace, one can 'secretly' look for a friend without the friend knowing (e.g. by walking past his or her office).  To this end, a key challenge for any location-enhanced IM design is in finding the right balance between plausible deniability and accountability.
   We also found that our "linearization" of the disclosure space probably wasn't right.  First, the control that "fuzzes" location information should be separate from the control that selects the amount of history to provide.  Secondly, it wasn't entirely clear that users would want fine-grained control over their location histories - most wanted either no history, or some fixed amount (e.g. since 9am this morning).
   Interview participants also wanted the ability to control the amount of fuzzed location they reveal using some sort of  semantic hierarchicy of places (e.g. "In the Allen Center", "On campus", "Off Campus").
   Some screenshots of our location enhanced IM application follow.

   This first screenshot shows the main interface. We can see that "justin" is online, "guest" is away, there is a message from "Bob", "welbourne" is out to lunch, and 4 other buddies are currently offline. To the right of each buddy is the "privacy slider" control, which indicates the number of times that buddy has checked your location (length of color), the type of information that buddy is getting (the color: blue = none, yellow=fuzzed, orange=exact, red=history), and allows the user to easily limit the rate at which that buddy can query (by clicking a limit-spot on the bar and thereby "locking" that level - as has been done for "welbourne").

   This screenshot shows how a user can modify the privacy settings with respect the user "guest" (a window opened by clicking the eye icon to the left of the privacy bar).  The top section adjusts the level of disclosure, the middle section is for setting the rate at which "guest" can access my location, and the bottom section is for setting how long "guest" can access my location information after I become disconnected (walk out of WiFi coverage).  The "Privacy" tab at the top of the main screen (above) opens a similar window to that below which allows the user to set default privacy preferences (and eventually for group privacy preferences).

   This screenshot shows an example of locating a buddy. In this example, "justin" is currently at Mary Gates Hall, and has just come from the Allen Center (Computer Science Building).