Understanding and capturing people s privacy policies in a mobile social networking application - PDF

Please download to get full document.

View again

of 12
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report



Views: 5 | Pages: 12

Extension: PDF | Download: 0

DOI /s ORIGINAL ARTICLE Understanding and capturing people s privacy policies in a mobile social networking application Norman Sadeh Æ Jason Hong Æ Lorrie Cranor Æ Ian Fette Æ Patrick
DOI /s ORIGINAL ARTICLE Understanding and capturing people s privacy policies in a mobile social networking application Norman Sadeh Æ Jason Hong Æ Lorrie Cranor Æ Ian Fette Æ Patrick Kelley Æ Madhu Prabaker Æ Jinghai Rao Received: 4 December 2007 / Accepted: 10 May 2008 Ó Springer-Verlag London Limited 2008 Abstract A number of mobile applications have emerged that allow users to locate one another. However, people have expressed concerns about the privacy implications associated with this class of software, suggesting that broad adoption may only happen to the extent that these concerns are adequately addressed. In this article, we report on our work on PEOPLEFINDER, an application that enables cell phone and laptop users to selectively share their locations with others (e.g. friends, family, and colleagues). The objective of our work has been to better understand people s attitudes and behaviors towards privacy as they interact with such an application, and to explore technologies that empower users to more effectively and efficiently specify their privacy preferences (or policies ). These technologies include user interfaces for specifying rules and auditing disclosures, as well as machine learning techniques to refine user policies based on their feedback. We present evaluations of these technologies in the context of one laboratory study and three field studies. N. Sadeh (&) J. Hong L. Cranor I. Fette P. Kelley M. Prabaker J. Rao ISR, School of Computer Science, Carnegie Mellon University, 5000 Forbes Avenue, Pittsburgh, PA , USA J. Hong L. Cranor P. Kelley 1 Introduction Over the past few years, a number of mobile applications have emerged that allow users to locate one another. Some of these applications are driven by a desire from enterprises to increase the productivity of their employees. Others are geared towards supporting social networking scenarios, such as meeting up with friends, or safety-oriented scenarios, such as making sure that a loved one returned home safely. The growing number of cell phones sold with location tracking technologies such as GPS or Assisted GPS ( A-GPS ) along with the emergence of WiFi-based location tracking solutions could lead to mainstream adoption of some of these applications. In this article, we report on work conducted at Carnegie Mellon University in the context of PEOPLEFINDER, an application that enables cell phone and laptop users to selectively share their locations with others, such as friends, family, and colleagues (see Fig. 1). This article extends a previous workshop paper in which we introduced PEOPLEFINDER [5], and provides a more thorough and detailed report of our user studies. Our objective has been to better understand people s attitudes and behaviors towards privacy as they interact with such an application, and to explore technologies that empower users to more effectively and efficiently specify their privacy preferences (or policies ). The work presented in this article confirms that people are generally apprehensive about the privacy implications associated with location tracking. It also shows that privacy preferences tend to be complex and depend on a variety of contextual attributes (e.g. relationship with requester, time of the day, where they are located). Through a series of user studies, we have found that most users are not good at articulating these preferences. The accuracy of the policies Fig. 1 PEOPLEFINDER is an application that lets users share their locations with others subject to privacy policies they can refine over time they define increases only marginally over time unless they are given tools that help them better understand how their policies behave in practice. Our studies included a combination of controlled lab experiments with 19 users and field studies involving a total of over 60 participants. Our results suggest that functionality that increases user awareness can contribute to the definition of more accurate policies. As our users grew more comfortable with PEOPLEFINDER and the way in which it was used by their acquaintances, they started refining their preferences and relaxing some of their policies to allow for requests that would have been denied under their initial policies. This suggests that functionality that empowers users to more effectively control their policies can contribute to the adoption of context-aware applications like PEOPLEFINDER. This article also compares results obtained in the context of controlled lab studies with results from longitudinal studies spanning up to several weeks. While both types of studies show that users have a hard time defining policies, our results suggest that users tend to be significantly more careful when defining policies that will be used to make decisions in actual situations (rather than under simulated conditions). To the best of our knowledge, the results from our field studies are the first of this type to analyze the behavior of users, the accuracy of their policies and how their policies evolve in the context of a fully deployed application with actual users. Finally, we also investigate whether machine learning techniques can be effective in helping to increase the accuracy of user policies. Our early results suggest that these techniques are promising. The remainder of this article is organized as follows. Section 2 gives a brief overview of related work. Section 3 provides an overview of our PEOPLEFINDER application. Section 4 discusses the privacy policy authoring functionality we have developed as well as several enhancements we are currently working on. An overview of PEOPLEFINDER s auditing functionality is provided in Sect. 5. Section 6 provides a summary of lab experiments we conducted in Summer Results and observations from a series of three pilot studies in which participants used the system as part of their daily lives in Spring 2007 are presented in Sect. 7. Section 8 has a discussion of results, and Sect. 9 presents some concluding remarks. 2 Related work From a high-level perspective, past work on location privacy can be grouped into three categories: computational, architectural, and user interface. Our work is most related to the user interface category. Computational approaches to location privacy propose algorithms for ensuring that disclosed data meets specified levels of privacy protection. Much of the work in this category strives to protect the anonymity of a set of users rather than a specific individual. More specifically, they typically aim for k-anonymity, in which disclosed data is anonymized such that there are at least k people sharing any combination of disclosed attributes. Thus, these algorithms strive to provide a guaranteed level of protection. Examples of this kind of work include Gruteser and Grunwald s work on spatial and temporal cloaking [7], and Beresford and Stajano s work on mix zones [3]. Other algorithmic approaches look at how to protect attackers from inferring more information about an individual, given a trace of that person s location information. For example, Krumm presented several techniques for determining the home address of an individual, given location data from volunteer users [17]. Krumm provides a comprehensive overview of the state of the art in computational privacy [18]. Architectural approaches to location privacy are system architectures meant to limit what location information is collected and/or how that information can be queried. Two examples of research systems that focus on the former are Cricket [23] and Place Lab [19] which rely on beacons in the infrastructure to locally compute a user s current location. These systems are more privacy protective than systems in which users broadcast information that allows the system to compute their current location, as in Active Badges [28]. Hitchhiking is another approach which looks at how busy places are rather than looking up the location of any specific individual [27]. Hightower and Boriello have published a survey of techniques for determining one s location [10]. Other systems focus more on restricting how location information is processed and queried. For example, Hong and Landay presented a system that computed, processed, and accessed data locally as much as possible, minimizing access to any network resources and thus maintaining some notion of privacy [13]. Canny and Duan [4] and Rastogi et al. [24] have presented work that limits what information people can see to situations where they were physically present. Canny and Duan have taken a cryptographic approach, whereas Rastogi et al. have taken an application programming interface approach. There has been a fair amount of user interface work looking at what information people are willing to share under what conditions, in the form of diary studies [2], interviews [9, 12, 15], surveys [20], and experience sampling techniques [6, 16]. Surveys by Lederer et al. [20] suggest that who is requesting the information is the primary factor in choosing whether to disclose information. Consolvo et al. [6] saw similar results using experience sampling, finding that the most important factors regarding disclosures were who was requesting one s location, why that person was making the request, and what level of detail would be most useful to the requestor. Other work has looked at the design and evaluation of working systems. This includes Reno, a mobile social system for sharing location information; MySpace, 1 a system for managing privacy policies governing what 1 Not to be confused with the popular social networking site with the same name. others could see about one s location, availability, calendar information and instant messaging [22]; and IMBuddy, a sister project of PEOPLEFINDER that looked at sharing information about one s location, interruptibility, and active window in the context of an enhanced instant messenger client [14]. PEOPLEFINDER builds on this past work by looking more deeply at what types of privacy policies people have, how good they are at specifying these policies and how they can be supported in that process. This work has involved a combination of both lab studies and actual field deployments spanning up to several weeks. Our work is not limited to designing policy authoring and auditing interfaces. Instead, we also present results suggesting that machine learning techniques can help refine the accuracy of people s privacy policies. 3 Overview of PEOPLEFINDER In PEOPLEFINDER, users rely on Policy Enforcing Agents (PEA) to handle queries about their location (see Figs. 2, 3). The user s PEA operates according to a policy (or set of rules) specified by the user, with each rule granting access to the user s location under a particular set of conditions (e.g. query coming from a particular group of users on one of several possible days and within one of several possible time windows). s can invite other people (e.g. friends, family members, or colleagues) to check their location with PEOPLEFINDER, using either a mobile phone client or the PEOPLEFINDER web site. s can specify rules under which other people can access their location and define groups of people to which particular rules apply. Fig. 2 Browser-based interface for finding the location of a person. Equivalent Java and C# applications are also available for laptops and several cell phones Jim 8 1 UI Agent MyCampus 2 Server 6 Alice s PeopleFinder Agent Alice s PEA 3 Alice s Privacy Rules Fig. 3 Processing Jim s request for Alice s location 7 Alice PEOPLEFINDER is available for Windows Mobile cell phones and for both PC and Apple laptops. The cell phone version relies on GPS technology to pinpoint the user s location. When no GPS reading is available (e.g. the user is indoors), the application falls back on a GSM triangulation solution developed by Intel Research Seattle [26]. While the GSM approach is not as accurate as GPS, it provides an estimate of the user s location, often within a few hundred yards, under a wider set of conditions. The laptop version uses a WiFi positioning solution developed by Skyhook Wireless [29]. In urban areas, this solution tends to have an accuracy of about 30 yards. It is complemented by an ad-hoc WiFi-based solution developed specifically for Carnegie Mellon s campus, which lets us estimate in what room a person is located when on campus. This latter solution, which uses a database of access points on campus, often provides readings that are even more accurate than the more general Skyhook Wireless solution. To understand how PEOPLEFINDER works, we need to distinguish between target users, namely users who are willing to share their locations with others, and requesting users, namely users who can submit queries about the location of one or more target users. A user can be both a target user and a requesting user, but does not have to be. Target users who rely on their laptops to track their location need to download an application on their laptops. This same application can be used for quickly finding a person as well as getting feedback about requests made about your location (discussed below, see Fig. 6). J2ME and C# versions of the application have also been developed for target users who rely on their cell phones to track their location, though these versions only work on a limited number of smartphone models. The smartphone version also lets users query for other people s locations. Figure 3 outlines the main steps involved in processing a query from a requesting user (Jim) for the location of a target user (Alice). The request submitted by Jim is 4 5 forwarded by his Interface Agent (e.g. Web browser or cell-phone application) to Alice s PEOPLEFINDER Agent. The agent invokes Alice s PEA to check whether the query is consistent with the privacy rules specified in her policy. If it is, a notification is forwarded to Alice s location tracking device, a cell phone in this example. Also, Alice s phone periodically updates her PEOPLEFINDER agent with her current location, regardless of whether anyone is requesting it. This design decision makes it faster for requesting users to see location information, as well as letting us provide a last seen functionality. Once returned, the location may need to be further processed by Alice s PEOPLEFINDER Agent (e.g. to combine multiple readings of Alice s location such as a GPS reading from a few minutes ago and a more recent reading based on GSM triangulation) before being forwarded to Jim. Finally, the results of the request are displayed on Jim s client, as shown in Fig. 1. When a request for a target user s location cannot be satisfied, PEOPLEFINDER returns an ambiguous message that does not allow the requester to determine whether the request was denied by the target user s policy or whether the target user s device (laptop or cell phone) could not be found. This provides a basic level of plausible deniability, in that a target user could claim to have forgotten to run the application, had her laptop off, or was simply out of range even if she actually had a rule in place blocking disclosure in this particular instance. In general, processing may be somewhat more complex and some privacy rules may in fact require checking Alice s location to determine whether or not to disclose her location. For instance, Alice may have specified that her colleagues can only access her location during weekdays and while she is on campus. Query processing could also involve the use of obfuscation rules that manipulate the accuracy of the response returned to a user [25]. PEOPLEFINDER is built on top of the MyCampus infrastructure, a semantic web environment in which policies are expressed using a rule extension of the OWL language [25]. The resulting language is capable of modeling a wide range of policies. Access to a user s location can be restricted according to conditions that refer to any number of concepts or instances of concepts defined in an open collection of ontologies (e.g. ontologies of locations, social relationships, and calendar activities). This includes capturing a variety of context-sensitive restrictions such as disclosing your location only when you are in a particular place, or enforcing obfuscation policies that allow users to specify how they want the application to manipulate the accuracy of their location before disclosing it (e.g. citylevel versus street address). Presently, PEOPLEFINDER only uses a small fraction of the policies that can be expressed in this framework. In fact, one of the questions our project is attempting to address has to do with how much expressiveness is actually required for users to feel comfortable using the application and to what extent adding more expressiveness enables users to more accurately specify their policies in contrast to creating more confusion. Finally, as noted earlier, we opted to store location information centrally on our servers, rather than taking a decentralized approach as advocated by past work [13, 19, 26]. Again, this let us provide a last seen functionality, but also made it much easier to quickly modify and update the system, an important consideration for rapid prototyping and for research. This centralized approach enabled us to develop thin clients on phones, with most of the functionality existing on our servers rather than on individual mobile devices. This decision made it easier for us to support a larger number of clients, an important consideration given the wide diversity of mobile phones in use today. However, in a centralized approach, the central server is a potential privacy vulnerability. 4 Privacy policy authoring s can define rules in which they grant access to their locations to individuals or groups of users. Each rule includes one or more restrictions such as the days of the week or times of day during which location queries from particular individuals or groups of users will be granted, as Fig. 5 s can also define locations as combinations of rectangular areas for use in location-sensitive privacy rules shown in Fig. 4. s can define user groups and place individuals in multiple groups. Extensions of the rule interface also allow users to specify locations as collections of rectangles on a map (e.g. all buildings in the school of computer science) and specify rules that include location-based restrictions (e.g. only disclose my location when I am in a school of computer science building), as shown in Fig. 5. To avoid conflicts in rules, we currently allow only rules that grant access to one s location rather than combinations of rules with some granting access and others denying Fig. 4 interface for defining simple privacy rules access. For example, a person can specify Mary can see my location between 9 AM and 5 PM, but cannot specify, for example, Colleagues cannot see my location on weekends. 5 Auditing functionality Results reported in Sects. 6 and 7 show that users often have difficulty anticipating the conditions under which their peers will use the application to access their location. To be effective, user interfaces have to be designed to increase user understanding over time of how the application is being used. We have found that simple bubbles that discreetly pop up (e.g. at the bottom of a laptop screen) to notify users that their location is being requested can go a long way in helping users feel more comfortable with the application (see Fig. 6). This feature is also intended to deter requesters from potentially abusing the system as they know their requests will be seen by target users a similar feature has been used in IMBuddy, a sister project [14]. An even more important element is the design of auditing functionality that enables users to review requests that have been submitted, see how they were processed by the rules they currently have in place, and possibly request a more detailed explanation to identify rules they m
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!