Privacy Issues of the W3C Geolocation API

Priv acy Issues of the W3C Geolo cation API Nic k Dot y , Deirdre K. Mulligan and Erik Wilde Sc ho ol of Information, UC Berk eley UC Berk eley Sc ho ol of Information Report 2010-038 F ebruary 2010 Av ailable at http://escholarship.org/uc/item/0rp834wf Abstract The W3C’s Geolo cation API ma y rapidly standardize the transmission of lo cation information on the W eb, but, in dealing with suc h sensitive information, it also raises serious priv acy concerns. W e analyze the manner and extent to which the current W3C Geolo cation API provides mec hanisms to supp ort priv acy . W e prop ose a priv acy framew ork for the consideration of lo cation information and use it to ev aluate the W3C Geolocation API, b oth the sp ecification and its use in the wild, and recommend some mo difications to the API as a result of our analysis. Con ten ts 1 In tro duction 2 2 Standards and Priv acy 2 3 Lo cation Information Priv acy 3 4 Priv acy F ramework 4 5 W3C Geolo cation API Sp ecification 6 5.1 User Agent Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2 Requesting W eb Site Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6 Requesting W eb Site Implementations 8 6.1 Metho d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7 Clien t Implementations and Lo cation Pro viders 11 8 T ry It Y ourself 13 9 F uture Developmen ts 13 10 Recommendations 14 UC Berkeley School of Information Rep ort 2010-038 Priv acy Issues of the W3C Geolocation API 1 In tro duction With the adven t of mobile access to the In ternet (early technologies, now mostly replaced by fully In ternet- capable access, were i-mo de and W AP), lo cation-based services ha ve b ecome an increasingly p opular part of the W eb, from restaurant-finding to driving directions to social net work location-sharing. The collection, use and disclosure of location information to pro vide suc h services implicates users’ priv acy and ph ysical safet y . Information ab out an individual’s lo cation routinely receives heigh tened priv acy protection under law and in so cial interactions. Curren tly the W orld Wide W eb Consortium’s Geolocation Applic ation Pr o gr am Interfac e (API) that enables scripting co de on a web page to access device lo cation information is the leading candidate for standardizing the transmission of lo cation information on the W eb. The API can b e rapidly deplo yed: W eb developers can simply write scripting co de to use this new browser functionality; no other part of w eb infrastructure need b e updated. This is a distinct adv antage o v er other p ossible mechanisms, such as extensions of the Hyp ertext T r ansfer Pr oto c ol (HTTP) [11], the main proto col used for communications on the W eb, or the dev elopment of a Uniform R esour c e Identifier (URI) scheme for lo cation [20]. Giv en the high likelihoo d of the broad adoption of the W3C Geolocation API and its exp ected influence on user priv acy and security , the current “last call” working draft 1 deserv es detailed analysis. The extent to whic h technical standards can and should pro vide the capacity for priv acy and other v alues to b e addressed is con tested. While few dispute the influence that technology and interface design hav e on priv acy , the exten t to which technology affirmatively should b e designed to supp ort priv acy- protectiv e outcomes is a live question. The authors ha v e a range of opinions on this topic and addressing this question as a general matter is beyond the scope of this pap er. How ever, w e do b elieve that it is imp ortan t to understand the strengths and limitations of the Geolo cation API with resp ect to supp orting priv acy . Without such an understanding it will b e difficult to address lo cation priv acy on the W eb whether through tec hnology , la w, norms or market forces. In this rep ort w e analyze the manner and extent to which the current W3C Geolo cation API provides mec hanisms to support priv acy . W e first discuss prior standards efforts to address priv acy concerns. Next, dra wing on U.S. law and normative conv entions around withholding and sharing lo cation information, we outline the priv acy and ph ysical safety concerns raised b y the wide av ailability of geolo cation information. W e then prop ose a priv acy framework for the consideration of lo cation information and use it to ev aluate the W3C Geolo cation API, b oth the sp ecification and its use in the wild. W e also identify issues that fall outside the scop e of the API but, given curren t market structures, raise additional priv acy issues that should b e addressed in a holistic consideration of lo cation information priv acy . In conclusion, we suggest four modifications to the API that w ould pro vide users with greater supp ort for their priv acy and ph ysical safet y concerns. 2 Standards and Priv acy A ttention to the effect of w eb standards on individual priv acy b egan in earnest in late 1994 when heated debate arose at the In ternet Engineering T ask F orce o v er proposed c hanges to the h yp ertext transfer protocol that standardized the abilit y of third-parties to set “co okies” in users browsers, but discouraged doing so [19]. A nascent netw ork adv ertising trade ob jected to defaults that would imp ede their business mo del b y limiting third-party “co okies” while priv acy advocates, the press and regulatory b odies weighed in on the other side ob jecting to the invisibilit y of the data collectors, the lack of user control, and the risks of data aggregation [19]. Beginning in 1996 the role of w eb standards — technical standards op erating at the application lay er that define, describe and supp ort the op eration of the W orld Wide W eb — in enabling 1 The most up-to-date version is the editor’s draft: http://dev.w3.org/geo/api/spec- source.html F ebruary 2010 2 of 17 UC Berkeley School of Information Rep ort 2010-038 Priv acy Issues of the W3C Geolocation API priv acy protection became an area of researc h, debate and standards activit y with the formation of the W orld Wide W eb Consortium’s Platform for Privacy Pr efer enc es Pro ject (P3P) [8, 9, 19]. Shortly thereafter, the IETF’s geographic lo cation priv acy (Geopriv) w orking group formed in recognition that “the represen tation and transmission of [lo cation] information has significant priv acy and security implications.” In resp onse to these concerns, Geopriv has “created a suite of proto cols that allow such applications to represent and transmit suc h lo cation ob jects and to allo w users to express policies on ho w these represen tations are exposed and used.” 2 In a similar vein, efforts to consider the p olicy implications of rights expression languages analyzed their abilit y to supp ort b oth the rights and limitations in cop yright law [22]. A t a higher level, several tec hniques for identifying and addressing the impact of technical design on v alues hav e b een offered with v arying effect [13, 21, 5]. In the area of priv acy sp ecifically researc hers hav e directed attention to the wa ys in whic h tec hnical design alters norms of information flo w [23], remov es structural barriers that pro vide de facto priv acy protection [28], increases visibility , transparency and exposure [6], introduces p ersisten t identifiers, facilitates monitoring and trac king and enables the collection and retention of information ab out individual users [21]. 3 Lo cation Information Priv acy Information ab out location — b oth real-time lo cation as well as permanent locations (such as home address) — is afforded special atten tion due to the consequences for both priv acy and physical safety that may flow from its disclosure. The heightened priv acy and physical safet y concerns generated by the collection, use and disclosure of lo cation information are apparent in U.S. law that creates restrictive consent standards for its use and disclosure in the priv ate sector in the context of telecomm unications services (47 USC § 222), court concern ab out the standards go verning law enforcemen t access to real-time and historical location information from telecomm unications pro viders under curren t la w 3 , as w ell as in limitations on the disclosure of departmen t of motor vehicle records under federal law [30], state la ws allowing sp ecific individuals to limit the disclosure of their address in public records [1] and the requirement to offer caller-id suppression services. A t the level of norms, the heightened sensitivity with which individuals regard lo cation information is reflected in social practices as w ell as empirical data. Paren ts and educators routinely remind c hildren not to give out their home address or their physical lo cation. This advice carries through strongly in educational efforts aimed at digital youth, where a primary rule of the road is to never giv e out address or location information to strangers or p ost it publicly . It is also reflected in a trend to remov e address information from phone directories, limit the av ailability of school contact lists, and other communit y efforts to protect the priv acy of home addresses. Surv ey data confirms this evident sensitivity of lo cation information priv acy . F or example, a recen t represen tativ e surv ey of Californians found strong support for judicial in terven tion and due pro cess b efore law enforcemen t are giv en access to historical location data (73% supp orting a la w requiring “p olice to convince a judge that a crime has b een committed b efore obtaining lo cation information from the cell phone compan y” [17]). Qualitative w ork exploring the use of lo cation-sharing platforms has found that a range of priv acy and security concerns influence decisions to share. F or example, one study found that who w as requesting information and the purp ose for the request had greatest influence o ver decisions to disclose or withhold, with the user’s lo cation and activit y being less imp ortant [7]. Relatedly , lo cation information has b een identified as the most sensitiv e element of information shared within social netw orks [26]. 2 http://www.ietf.org/dyn/wg/charter/geopriv- charter.html 3 http://www.eff.org/related/3494/pressrelease F ebruary 2010 3 of 17 UC Berkeley School of Information Rep ort 2010-038 Priv acy Issues of the W3C Geolocation API 4 Priv acy F ramew ork Ac knowledging the priv acy and safety considerations attending lo cation information is helpful, ho wev er what is needed at this p oin t is guidance ab out what issues can and should b e addressed at the API level. Theoretical and prescriptiv e work on protecting priv acy exists in several fields. The framework we dev elop b elo w dra ws primarily from researc h in the law and computer and h uman in teraction fields. Muc h of the legal framew ork for protecting priv acy , including location information priv acy , derives from the F air Information Practice Principles that are premised on the concept of “informational self- determination” and are substantiated in pro cedural rules that establish: individual rights of data sub jects to control the collection and reuse of p ersonal information, and access and correct or amend or delete p ersonal information held by organizations; and, organizational obligations to minimize the collection of p ersonal information, provide safeguards against misuse and unauthorized access and resp ect the rights of data sub jects [24]. Alternative frameworks for analyzing priv acy hav e been adv anced, most notably priv acy as “contextual integrit y” whic h fo cuses priv acy analysis on norms of information flows that inhere in v arious con texts and considers their violation to signal a p oten tial priv acy transgression [23]. Priv acy understo od as “a p ersonal notion shap ed b y culturally determined exp ectations and p erceptions ab out one’s environmen t” has b een found to require feedback (“informing p eople when and what information ab out them is b eing cap- tured and to whom the information is b eing made av ailable”) and control (“emp o wering p eople to stipulate what information they pro ject and who can get hold of it”) b y sub jects [4], mec hanisms for ongoing boundary con trol [2, 25] and a recipro city of kno wledge and exp osure b et w een users and observers [4]. Researchers ha ve explored v arious mechanisms for represen ting b oundaries [25], information flo ws and context to users to enable decisions ab out the disclosure of p ersonal information. Related w ork on lo cation priv acy standards in the IETF Geopriv working group tak es a play out of the con tent managemen t environmen t and builds a mec hanism through which users can attac h policies to their lo cation information. This turns the standard pro cesses of priv acy law and practice that rely on entities pro viding notice to users through priv acy p olicies on web sites to which users can choose whether to consent on their head. Core elemen ts of the Geopriv approac h are “limiting the distribution of lo cation information to authorized entities” and sp ecifying policies for retention. Geopriv also incorp orates a feature to supp ort the data protection concern of minimization b y providing alternativ e means for represen ting lo cation at v arious lev els of granularit y with presumptively corresp onding levels of priv acy and safet y concerns. Sp ecifically , Geopriv supp orts “geo detic lo cation data (latitude/longitude/altitude/etc.) as well as civic lo cation data (street/cit y/state/etc.)” [3]. The W3C Platform for Priv acy Preferences pro vides a set vocabulary that web sites can use to state their priv acy p olicies in XML format. User agents can read and interpret these p olicies and presen t their conclusions to users or, through user delegation, act up on them. P3P increases the transparency of web site practices and facilitates notice and c onsen t b y reducing transaction costs associated with priv acy communi- cations through standardization and mac hine readability . The P3P sp ecification includes a v o cabulary that constrains the statemen ts that can be made ab out priv acy p olicies. Conforman t P3P polices must pro vide con tact information for the legal entit y making the representation of priv acy practices, as w ell as a URI for the human readable p olicy . They m ust enumerate the t yp es of data or data elements collected, explain ho w the data will b e used, indicate whether and what access rights are av ailable, and identify the data recipients. The vocabulary also supp orts statements ab out the consequences of information use under the p olicy . The priv acy frameworks and sp ecifications iden tify imp ortan t common elemen ts that m ust b e incorp o- rated into a framework to ev aluate lo cation information priv acy . Sp ecifically , the fo cus on facilitating end user con trol ov er decisions about whether and in what circumstances to disclose location information is fa- cilitated alternatively by user communication of priv acy rules and control ov er lo cation disclosure, or by the principles of notice and consent prior to the disclosure of lo cation information. Consen t is made meaningful b y required disclosures ab out the purpose of the request, in tended secondary uses or disclosures and reten- F ebruary 2010 4 of 17 UC Berkeley School of Information Rep ort 2010-038 Priv acy Issues of the W3C Geolocation API tion perio ds. Knowledge, consent and feedbac k is further supported b y mec hanisms that allow users access to the data maintained ab out them and the ability to amend or delete it. Researc h suggests that feedback impro ves user comfort and alla ys priv acy concerns [29]. Based up on a review of existing frameworks and prior standards that address priv acy we suggest the follo wing framework of common questions for analyzing the priv acy supp ort provided by a technical standard. W e frame the an alysis in terms of supp ort to ackno wledge b oth the range of influence that tec hnical standards can hav e on priv acy as well as the p ow er of other constraints, such as law. In considering the impact of tec hnical standards we in no wa y mean to suggest that the standard alone can or ough t to indep enden tly determine lo cation priv acy . In fact, the determination of where the regulatory hand-off betw een tec hnological, legal, mark et and normative constrain ts o ccurs is of utmost imp ortance. In an area with complex and context- dep enden t laws and norms about information flo ws, standards will do b est to enable v ariation rather than dictate a single outcome [5]. • Appr opriateness: Is the collection of lo cation information appropriate giv en the context of the service or application? • Minimization: Is the minim um necessary gran ularity of lo cation information distributed or collected? • User Contr ol: How muc h ongoing con trol does the user hav e o ver lo cation information? Is the user a passiv e receiv er of notices or an activ e transmitter of p olicies? Are there defaults? Do they privilege priv acy or information flo w? • Notic e: Can requesters transmit information about their iden tit y and practices? What information is required to b e provided to the user by the requesting en tity? What rules can individuals establish, attac h to their lo cation information and transmit? Is there a standard language for such rules? • Consent: Is the user in control of decisions to disclose location information? Is con trol pro vided on a p er use, p er recipient or some other basis? Is it op erationalized as an opt-in, opt-out or opt mo del? • Se c ondary Use: Is user consent required for secondary use (a use b ey ond the one for whic h the infor- mation was supplied b y the user)? Do mec hanisms facilitate setting of limits or asking p ermission for secondary uses? • Distribution: Is distribution of lo cation information limited to the entit y with whom the individual b eliev es they are interacting or is information re-transmitted to others? • R etention: Are timestamps for limiting retention attac hed to lo cation information? Ho w can p olicy statemen ts ab out retention b e made? • T r ansp ar ency and F e e db ack: Are flows of information transparen t to the individual? Do es the specifi- cation facilitate individual access and related righ ts? Are there mechanisms to log lo cation information requests and is it easy for individuals to access such logs? • A ggr e gation: Do es the standard facilitate aggregation of lo cation information on sp ecific users or users generally? Does the sp ecification create persistent unique iden tifiers? Collectiv ely , answers to these questions pro vide insigh t in to the capacit y of the sp ecification to supp ort in teractions under a range of priv acy conditions. In the following sections we consider how these questions are addressed b y the W3C Geolocation API specification and its current implementations. F ebruary 2010 5 of 17 UC Berkeley School of Information Rep ort 2010-038 Priv acy Issues of the W3C Geolocation API 5 W3C Geolo cation API Sp ecification The W3C Geolo cation API [27] pro vides a simple, high-level Ja v aScript API to allo w web sites to request lo cation information — primarily latitude and longitude co ordinates — from web browsers, whether on a mobile phone or a laptop computer or an y other W eb-capable device. The API itself is agnostic to how the browser or device determines the curren t lo cation: a phone or other mobile device might use a Global P ositioning System (GPS) receiver, while a laptop’s location might b e triangulated from nearby Wi-Fi net works or inferred from its IP address. W eb sites may either request a “one-shot” lo cation — commonly used to lo cate the user on a map or sho w nearby p oin ts-of-in terest — or register with the browser to receive regular up dates, which may b e used to give directions as the user mo ves through a cit y , for example. In eac h case, precise lo cation information (latitude and longitude, and sometimes also altitude, heading and sp eed) is pro vided to the calling Ja v aScript co de along with accuracy information (measured in meters and corresp onding to a 95% confidence lev el). This Jav aScript co de runs inside the browser on the user’s o wn mac hine, but in most cases it immediately comm unicates the user’s location to the hosting w eb server or some third-part y serv er (like Go ogle Maps, for example) using AJAX or an equiv alent metho d. The sp ecification provides normative requirements for b oth use r agents (the web browser) and recipients (the requesting web site) in order to protect user priv acy . (Normativ e requiremen ts are binding for any implemen tation that conforms with the standard.) Requirements may b e functional — gov erning the actual API function calls betw een the bro wser and web site — or non-functional — obligations for the bro wser or w eb site that don’t directly affect the op eration of the API. The sp ecification also includes non-normative (that is, non-binding) recommendations and leav es other questions completely op en to the implementer’s discretion. Both the choice of normativ e requirements (or the lack thereof ) and whether those requirements are functional or non-functional affect user priv acy in practice. 5.1 User Agen t Requirements Most of the normativ e priv acy requiremen ts on user agen ts (typically web browsers) are functional, specifying do wn to the ordering of distinct steps the algorithm for returning the user’s lo cation. Most notably , the user agen t m ust, in most cases, get the user’s express p ermission to send the device’s lo cation to a particular w eb site b efore initiating a pro cess to obtain a cached or new location. This directly addresses the c onsent question of our priv acy framew ork: users are given yes-or-no con trol b efore their information is obtained or rev ealed. The sp ecification requires that the user agent iden tify the w eb site by its do cument origin , as defined b y HTML5 [15]. The do cument origin sp ecifies which web site is theoretically resp onsible for requesting the lo cation, although the Ja v aScript code itself may hav e come from a third-part y serv er (w eb sites commonly include Jav aScript from Go ogle in order to do basic traffic monitoring, for example) and the Jav aScript co de ma y communicate the information to a different, third-party serv er without the user’s knowledge or consent. Pro viding the do cumen t origin gives the user some notic e of which entit y is requesting their information (though it is silent with resp ect to their practices), but do esn’t address questions of distribution , since users ha ve no assurance ab out which en tities may ultimately receiv e their lo cation. In certain cases, the user agent does not hav e to obtain express p ermission from the user before obtaining and sending lo cation. First, if the user agent has a “prearranged trust relationship” with the requester — the example given in the spec is the case of a V oIP telephone with an E911 function to inform emergency services of the user’s location — then the user agen t need not show a user interface or request p ermission. No implementing web browser (Firefox, Mobile Safari, Op era) currently has default “prearranged trust relationships” with la w enforcemen t or any other web site, and it is not clear how this phrase, not explicitly defined in the sp ec, will b e interpreted by user agen ts. The priv acy impacts of such pre-arranged relationships w ould turn on their appr opriateness : users are likely to exp ect and appreciate automatic transm ission of F ebruary 2010 6 of 17 UC Berkeley School of Information Rep ort 2010-038 Priv acy Issues of the W3C Geolocation API their lo cation when requesting emergency services but would consider it inappropriate for their user agent to automatically trac k their lo cation history while browsing in order to provide targeted adv ertising. Second, users may p ersist their p ermissions for a particular web site to access their lo cation. Commonly when a user is asked to giv e p ermission to a web site, the bro wser also presents an option to remember their answer (whether negative or affirmative). If a user asks the browser to remember that they hav e giv en permission to a w eb site, then the bro wser is not required to present any user interface or obtain p ermission the next time the user accesses that web site and the web site requests the user’s lo cation. These p ermissions p ersist even if the purp ose for whic h the web site is collecting location information or its practices of secondary uses, retention and re-distribution change; in fact, even a conscientious requesting web site has no wa y of signaling to the user agent that their p olicies hav e changed and the user should be prompted again. The specification pro vides no requirements on whether p ersisten t p ermissions should expire ov er time and bro wser implemen tations v ary on this p oint. User agents are required to let users manually revok e p ersisted p ermissions and are advised “to provide easy access to interfaces that enable rev o cation” [27, Section 4.3], but browser implementations v ary on ho w easy this is in practice. F or more details, see Section 7 . W eb sites may either request an old p osition that the user agent has cached, or insist that a new lo cation b e obtained. The specification pro vides no requiremen ts or recommendations on ho w long bro wsers may or should cache a user’s lo cation, and provides no metho d for users to see what cached lo cation (whic h may not b e their current lo cation) will b e provided to the requesting co de. Nor can users ov erride or control whether new or cached lo cations are pro vided. Enabling users to insp ect lo cation data b efore sending it could supp ort the tr ansp ar ency of the system and let users censor sensitiv e locations. The sp ecification provides a non-normative (that is, non-binding) section of “Additional implementation considerations” for user agents which recommends (though do es not require) that web bro wsers “enable user a wareness of location sharing” [27, Section 4.3]. Such features w ould also supp ort tr ansp ar ency , but, as describ ed in Section 7 , w eb browsers don’t currently pro vide any ambien t feedbac k to the user to remind them when their lo cation is b eing shared. Finally , the current draft of the API pro vides no requiremen t for the ability of clients to send a “fuzzed” lo cation or an ything less granular than the exact latitude and longitude (just the city and state, for example). Y aho o’s Fire Eagle lo cation broker provides this functionality at eight different levels of gran ularity 4 and the Firefox Geo de feature (a forerunner to the W3C API) provided four different lev els of granularit y . 5 The W orking Group is considering something lik e this functionalit y for the second v ersion of the API, 6 but this has b een ruled out of scop e for the curren t v ersion o ver concerns that naive fuzzing algorithms could b e circumv ented by making multiple requests ov er time. 7 As a result, the API cannot fulfill the priv acy principle of data minimization : even in cases where the web site ma y not need the exact lo cation, the API alw ays requires that the precise latitude and longitude b e sen t. The API provides users a choice b et ween allo wing real-time trac king of precise lo cation or b eing unable to use location-based services. 5.2 Requesting W eb Site Requirements Although the primary audience for (and the primary authors of ) the sp ecification are the v arious browser mak ers (Apple, Go ogle, Mozilla and Op era will ha ve to implemen t the API as part of their bro wsers), the sp ecification also puts normativ e requirements on requesting w eb sites that use the API in their Jav aScript co de [27, Section 4.2]. W eb sites that do not satisfy the “Priv acy considerations for recipients of lo cation information” are not considered conformant with the sp ecification, 8 but as a practical matter the W3C lacks 4 http://fireeagle.yahoo.net/developer/documentation/location 5 http://mozillalabs.com/blog/2008/10/introducing- geode/ 6 http://www.w3.org/2008/geolocation/track/products/2 7 http://www.w3.org/2008/geolocation/track/issues/18 8 http://lists.w3.org/Archives/Public/public- geolocation/2009Oct/0009.html F ebruary 2010 7 of 17 UC Berkeley School of Information Rep ort 2010-038 Priv acy Issues of the W3C Geolocation API an y pow er to enforce web site practices, and th us there is no clear negativ e consequence for non-conformance. Nev ertheless, the W3C sp ecification insists that web sites which request visitors’ lo cations using the API meet strict requirements for notice, consen t and usage of visitor lo cation information. Without the express p ermission of the user, w eb sites must not use lo cation information for purp oses b ey ond whic h it w as pro vided to them, retain lo cation information longer than p ermitted or retransmit the visitor’s lo cation. Also, web sites m ust “clearly and conspicuously disclose” that they are collecting visitor lo cation data, how long it is kept, ho w it is secured, whether it is shared, and how visitors may access, up date or delete it. These requiremen ts directly and explicitly address the appr opriateness , notic e , c onsent , se c ondary use , distribution , r etention and tr ansp ar ency asp ects of user priv acy . But though these requiremen ts are normative sections of the specification, they are not functional require- men ts that directly influence how the API w orks. None of these notices are communicated as part of API calls, and none of these requirements are enforced b y the user agent (as a practical matter, it is imp ossible to enforce them, b ecause the API do es not provide any wa y in which this enforcemen t could be supp orted). Instead, web sites are exp ected to use the HTML conten t of their o wn pages to mak e details ab out collection, usage, storage and access clear to their visitors. The sp ecification do es not detail any particular interface or language requiremen ts and no de-facto standards exist. W eb sites v ary in their implemen tation of these rules and v ery often fall short; see Section 6 for an initial survey of sites using the API. The W3C Geolo cation W orking Group did consider multiple prop osals that would hav e added functional requiremen ts for requesting w eb sites: making either transmitted priv acy preferences from the user 9 or notification of intended usage from the w eb site 10 part of the API function calls. The Geopriv prop osal [10, 12], designed and endorsed by the IETF, 11 w ould hav e allow ed users to attach a set of p ersonal rules to their lo cation information so that requesting web sites would b e informed in a mac hine-readable w a y whether the user p ermitted long-term storage or re-transmission of their lo cation information. Suc h a prop osal would also ha ve c hanged user c ontr ol of location information from passive (users receiving and accepting notices) to activ e (users transmitting their own preferences). In a conten tious vote, the W orking Group chose not to adopt the Geopriv prop osal for the curren t draft of the sp ecification, with opp onents arguing that it w as to o complex to be widely used or understo o d by web site developers or novice users. 12 The W orking Group leadership also rejected prop osals to ha ve websites send an in tended usage notification and fields specifying reten tion time and whether or not information would b e retransmitted, which would hav e standardized and enforced notice of se c ondary use , distribution and r etention policies. Opp onen ts feared that such a system w ould ero de user trust in web browsers since web site priv acy practices could not b e enforced by the browser itself, 13 while proponents (including one of the authors) suggested that this need not be an y differen t than displa ying other third-part y information. 14 6 Requesting W eb Site Implemen tations Although the W3C Geolo cation API is only in draft form, its presence in p opular browsers (iPhone’s Mobile Safari and Firefox 3.5+) has led some web sites to make use of it already . W e sought to catalog and ev aluate the p opular web sites that use the API to day and their priv acy p olicies: b oth whether they satisfied the “Securit y and priv acy considerations” section of the API and whether they made their practices clear to the user up front, b efore in voking the API. The normative, non-functional requirements put on web sites by the API specification emplo y a traditional model of notice and consent and rely on web sites to proactiv ely 9 https://datatracker.ietf.org/liaison/486/ 10 http://lists.w3.org/Archives/Public/public- geolocation/2009Mar/0131.html 11 http://www.ietf.org/dyn/wg/charter/geopriv- charter.html 12 http://www.w3.org/2008/12/08- geolocation- minutes.html#item02 13 http://www.w3.org/2008/geolocation/track/issues/10 14 http://lists.w3.org/Archives/Public/public- geolocation/2009Apr/0054.html F ebruary 2010 8 of 17 UC Berkeley School of Information Rep ort 2010-038 Priv acy Issues of the W3C Geolocation API pro vide clear, conspicuous and comprehensive notice; w e sough t to inv estigate whether such notice was actually present. 6.1 Metho d T o obtain a corpus of w eb sites using the API, w e used the 80legs 15 distributed w eb-spidering service to cra wl 11 million URIs and search their Jav aScript co de (b oth inline in HTML co de and in separate Ja v aScript files) for references to the API. 80legs do es not choose URIs randomly from the trillions of URIs on the W eb to da y; w e seeded our searc h with the 10,000 domains that receiv e the most traffic according to alexa.com and our 80legs co de follow ed links on those pages to other w eb sites. On obtaining results from the cra wl, w e manually in vestigated each w eb site that matched our search to determine whether it w as actually using the API, what it apparently used the API for, whether the user w as informed of the site’s practices with user location information before b eing prompted for p ermission, whether user lo cation information w as men tioned in the site’s Priv acy P olicy and whether the relev ant Priv acy Policy w as easily accessible (with a single click, for example) from the page where the user was prompted. W e also in vestigated one aspect of user c ontr ol and distributional norms: whether users could insp ect their location information and then choose whether to submit it to the requesting site. W e remov ed from the list any page that w as clearly just a test page (like our o wn) to exp erimen t with the API, any page that was not actually using the API (some pages were simply desc ribing the API without using it themselv es and others had the code necessary for the API but did not activ ate it) or any page we couldn’t test (some were b ehind membership walls). W e added some sites to our list that were not found in the automated cra wl that were rep orted to us b y participan ts in the Geolo cation W orking Group. The full list of sites is a v ailable online at http://npdoty.name/location/services . Since this w as compiled during the F all, undoubtedly some sites that we crawled ha v e since added supp ort for the API; our analysis of the priv acy practices of this list is current as of F ebruary 2010. F or sev eral reasons, our list should not b e considered a comprehensiv e or exhaustive search of web sites using the API. 11 million URIs is a tiny fraction of the W eb and our cra wling algorithm w as not exhaustive of all pages on each of the high-traffic domains it was seeded with. Some web sites only transmit co de that uses the API if the bro wser is iden tified as running on a mobile phone: the 80legs crawler is not. F urthermore, some w eb sites use the Rob ot Exclusion Standard to sp ecifically preven t automated cra wlers from accessing Ja v aScript files. Finally , it is p ossible that some co de that our crawler accessed might not ha ve used the particular string we searched for (“na vigator.geolo cation”) in calling the API. But though our list of 22 implemen ting w eb sites is not exhaustiv e, w e do b eliev e that it pro vides a useful sample of API usage that users are lik ely to encounter. 16 6.2 Results Analysis of the 22 implemen ting w eb sites revealed a v ariety of practices in notice to the user and usage of lo cation data. But for the most part, curren t implementing web sites do not “clearly and conspicuously” disclose the purpose and practices of their collection of users’ lo cation information. Sites are listed in Figure 1 ordered b y their Alexa ranking; the bottom sev en sites in the list are unranked. No site informed users of their information practices b efore requesting the user’s lo cation (the first column). In the second column, sites where the priv acy policy did not explicitly cov er location information are noted with a red X, while sites with a clear priv acy p olicy easily accessible from the requesting page are noted with a green c heckmark. In the third column, sites that allow insp ection of location information before submitting 15 http://80legs.com 16 W e’re currently exploring techniques that would allo w us to make an ev en broader and more comprehensive search of w eb sites; if successful, we will update our list and analysis with the additional data. F ebruary 2010 9 of 17 UC Berkeley School of Information Rep ort 2010-038 Priv acy Issues of the W3C Geolocation API What does it do? Informed up front? In Privacy Policy? Lets user inspect? Google Maps Zoom the map to your location. ✖ ● ✖ Google Local Nearby points-of-interest. ✖ ✔ ✖ Flickr Show pictures taken nearby . ✖ ✖ ✖ T ravelocity iPhone Search for nearby hotels. ✖ ✖ ● AskLaila Search for businesses in India. ✖ ✖ ● Search.ch Find Swiss train schedules. ✖ ✖ ✖ Identi.ca Attach your location to public microblog posts. ✖ ✖ ✖ Foreca Weather Get the weather forecast. ✖ ✖ ✖ BooRah Restaurants Show restaurants near you. ✖ ✖ ✖ GoThere Singaporean points of interest. ✖ ✖ ✖ The Rocky Horror Picture Show Find Rocky Horror showtimes nearby . ✖ ✖ ✖ GraffitiGeo Show tagged locations nearby . ✖ ✖ ✖ GeoMail Add your location to an email. ✖ ✖ ● Our Airports (mobile) Show nearby airports. ✖ ✖ ✔ Our Airports Show nearby airports. ✖ ✖ ✔ Plemi Find nearby concerts. ✖ ✖ ✖ AskAround.Me Answer geotagged questions. ✖ ✖ ✖ gMapT ip WordPress Add a map to a blog post. ✖ ✖ ✖ Y our Mapper See map data for your location. ✖ ● ✔ BackNoise Semi-private conversations. ✖ ✖ ✖ BailBond.com Find a nearby bail bondsman. ✖ ✖ ✔ T oupil.fr Search for businesses in France. ✖ - ✖ Figure 1: Web sites using the W3C Ge olo c ation API. F or a complete and up-to-date list, see http://npdoty. name/location/services are noted with a green chec k and sites that w ait to submit lo cation information until the user submits a form are noted with an orange circle. Out of 22 instances, not a single w eb site informed users of their priv acy practices with resp ect to collected lo cation data up front, that is, b efore they were presented with a prompt for their lo cation. As a result, w e s uspect that virtually no users encountering the W3C Geolocation API are fully informed ab out the requesting site’s information practices when they decide whether or not to reveal their lo cation. Nine sites (41%) presen ted the prompt immediately on loading a page, without a user even pressing a button to initiate the action. F urthermore, only four of the 22 sites (18%) explicitly mentioned the collected location data in their F ebruary 2010 10 of 17 UC Berkeley School of Information Rep ort 2010-038 Priv acy Issues of the W3C Geolocation API priv acy p olicy (if a priv acy p olicy ev en existed), making it difficult for even a determined user to find out p olicies on distribution or r etention . Only one site (the mobile v ersion of Go ogle Lo cal) had a priv acy p olicy with a clear description of the collected lo cation data av ailable within a single clic k. In the case of the microblogging site Identi.ca, logged-in users are immediately presented with the lo cation prompt on loading every page with no explanation of what their lo cation will be used for, casting doubt on the appr opriateness of the request. (The prompt ev en appears on their priv acy page, whic h does not men tion lo cation information.) Users who do provide their lo cation ha v e it silently and automatically attached to the p osts they mak e on the site, whic h are published (alongside their usernames) publicly for ev eryone to see, a form of distribution they may not expect. There was one encouraging sign for priv acy protection: sev en of the sites (32%) did not immediately submit the user’s lo cation back to the originating web server once it was received. Instead, they entered the receiv ed lo cation data into a form field on the page itself; lo cation information would only b e sent to the serv er if and when the user submitted the form by clicking a button (with lab els like “Search”). In some of these cases (four of the seven), the user can even insp ect or mo dify the lo cation data b efore it is sent: to correct a mistake that their browser made, censor a sensitiv e lo cation that they do not wan t to share, decrease the precision of the lo cation data b eing sent or simply to b e aw are of what p ersonal information is being pro vided to the w eb site. F or example, pilots who use OurAirports.com can clic k “Use m y current lo cation” to bring up the Geolocation API prompt, after whic h their latitude and longitude is presen ted in plain text in the search box, where a pilot can edit it before finally clicking “Go!” to find nearby airp orts. Suc h tec hniques, though uncommon in our survey , matc h common expectations for ho w forms on the W eb w ork, enable real tr ansp ar ency and maximize user c ontr ol . Of course, b ecause the API currently returns lo cation data exclusively in latitude and longitude co or- dinates, v ery few users (other than pilots) can mak e sense of co ordinate data they are ab out to send, ev en if they are pro vided an opp ortunity to inspect or change it. BailBond.com and Y ourMapp er.com tak e the helpful step of r everse ge o c o ding the user’s lo cation, translating it into a human-readable city and state, but this requires first transmitting the user’s co ordinates to a service (GeoNames and Go ogle, resp ectively) to do the geoco ding without the user’s notice or consent. 7 Clien t Implemen tations and Lo cation Pro viders W e hav e not completed a systematic analysis of supp orting W eb browsers, but p opular implementations (Firefo x 3.5+ and Mobile Safari 3.0+) 17 do v ary . All bro wsers explicitly request the user’s p ermission through a UI b efore revealing lo cation. But p ersistence of p ermissions (after which the user is not prompted an ymore) v aries: in Firefo x, users c heck a box lab eled “Remember for this site”; on the iPhone, the user’s preference is remem b ered after t w o consecutive answers. The sp ecification requires that user agents provide a wa y to rev oke these p ersisted p ermissions and advises that they “provide easy access to interfaces that enable revocation”. In Firefo x, this requires returning to the page in question (risking that the site will again automatically obtain your lo cation) and viewing the p ermissions for the page in “P age Info”. On the iPhone, p ersisted p ermissions are automatically reset after 24 hours. Users can manually reset location warnings for all applications on the phone through a series of men us in the phone’s settings, but this resets all lo cation information p ermissions granted by the user; there is no wa y to revok e location p ermissions for a single application or site. Once the user has giv en permission for Mobile Safari (which in this logic is just a single application providing access to lo cation information) to access their location, the iPhone remembers an y previously set site-specific p ermissions. 17 Beta and exp erimen tal versions of the Op era browser also supp ort the API, but this functionalit y hasn’t b een released as part of the main pro duct. Google Chrome and other browsers with the Google Gears plugin support similar functionality but with a distinct API. F ebruary 2010 11 of 17 UC Berkeley School of Information Rep ort 2010-038 Priv acy Issues of the W3C Geolocation API Although web browsers “are advised to enable user aw areness of lo cation sharing” neither Firefox nor Mobile Safari pro vide any sort of am bient notification to the user when location data is automatically sent to a w eb site for whic h permissions are p ersisted. Similar functionality do es exist today at the operating system lev el: the Windows 7 Lo cation Platform 18 pro vides unobtrusiv e taskbar notifications when an application accesses the user’s lo cation and also lets users view a retrosp ectiv e log of lo cation activity (whic h applications accessed the user’s lo cation and when). 19 Finally , although the sp ecification is agnostic to how implemen ting user agents determine the user’s lo cation, the details can affect user priv acy . F or example, Firefox sends a list of the user’s Wi-Fi SSIDs and signal strengths to Go ogle Location Services in order to estimate lo cation, and Google stores that list along with the user’s IP address and a unique client identifier. 20 On the iPhone (and in the Op era web bro wser), Wi-Fi triangulation is done through Skyho ok Wireless, which has a similar priv acy p olicy . 21 There are several different tec hniques that could b e used for geolo cating a particular W eb-based device: • Ge olo c ation by IP A ddr ess: If the IP address of a device is known, the general geographic area can b e inferred. The result v aries widely in accuracy and is based on the assumption that an IP address b elongs to an IP address blo ck that can be asso ciated with a physical lo cation. This assumption can b e problematic in a v ariet y of settings, such as with dynamic IP addresses, VPNs, proxy serv ers, NA T, and other net work-lev el technologies that influence IP address assignmen t. • Ge olo c ation fr om Wi-Fi Networks: F or devices that hav e Wi-Fi access, the SSID (a netw ork identifi- cation co de) of nearby netw orks can b e used to lo okup the geolo cation of that wireless netw ork in a database of SSIDs. This metho d is often reliable, but suffers from the fact that SSIDs are not unique and can c hange position. • Ge olo c ation by Cel l T ower T riangulation: F or devices using mobile phone netw orks, cell to wer IDs can b e used to determine lo cation by triangulation (using v arious IDs and the signal strength to calculate the most lik ely location). The accuracy of this metho d v aries with the cell tow er density . • GPS: An increasing num b er of devices ha v e GPS receiv ers built-in, which pro duce very accurate lo cation measuremen ts. GPS has the disadv an tages of b eing less reliable indo ors, b eing affected by the visible sky in a given lo cation and potentially taking a long time to fix on a location. • Manual Input: Users can also manually specify their lo cation, either selecting from a predefined list, or using in terfaces with map views whic h might b e initialized b y a differen t location technology . (No bro wser implementations of the W3C Geolo cation API support man ual input to da y .) Because the sp ecification is agnostic to ho w lo cation is pro vided, user agent implementations could allow users to choose betw een different providers or different metho ds under differen t circumstances, to obtain more accurate location information in certain circumstances or to hide sensitiv e locations from a particular pro vider. F or example, Firefox could provide an interface that let users man ually sp ecify their lo cation (Fire Eagle provides suc h functionality for its lo cation broker service) or the iPhone could provide a setting to only use GPS for lo cation services (whic h would decrease their sp eed and accuracy in some circumstances, but preven t Skyho ok or Apple from b eing informed of the user’s lo cation). But as a matter of fact, Google and Skyho ok act as the pro vider for the v ast ma jority of users of the W3C Geolocation API to da y . Using large, centralized lo cation pro viders not only is more economical for device and browser manufacturers then implemen ting such a service in-house, it also allows providers to use the large volume of lo cation requests to contin uously improv e and correct their databases, for example, to detect when a particular Wi-Fi access 18 http://www.microsoft.com/whdc/device/sensors/ 19 http://msdn.microsoft.com/en- us/library/dd756632(VS.85).aspx 20 http://www.google.com/privacy- lsf.html 21 http://www.skyhookwireless.com/howitworks/privacypolicy.php F ebruary 2010 12 of 17 UC Berkeley School of Information Rep ort 2010-038 Priv acy Issues of the W3C Geolocation API p oin t has suddenly mov ed. But such centralization has the side effect of enabling large-scale aggr e gation of user lo cation data: although a user might rev eal his lo cation to several differen t lo cation-based services throughout the course of a da y , the user reveals his location to the same location provider eac h time, whic h can pro duce a full, sensitiv e and p ersonally-identifying lo cation history for a pseudon ymous user. The priv acy risks of large-scale aggregation on the W eb are not new: the Kno wPriv acy pro ject [14] and a study b y Krishnam urthy and Wills [18] illustrate some of the possible threats. Recent regulator and public concern ab out the retention of search queries is also applicable to these back end lo cation pro viders; although they collect different data, aggregated lo cation data raises not only a similar priv acy concern but also a safety concern, since a large num b er of individuals ma y be ph ysically located with such a dataset. 8 T ry It Y ourself Since a handful of browsers and w eb sites are already using the draft W3C Geolo cation API, it is not difficult to try this new functionality for yourself. Use an iPhone (with v3.0 or higher soft ware) or a recent version (3.5 or higher) of the free Firefo x browser and navigate to our test page at http://npdoty.name/location . On loading the test page you can immediately see the accuracy of the legacy , non-Ja v aScript metho d for determining the user’s location. Just b y receiving the request, a web site can guess location (sometimes to the city level of precision) from the user’s IP address. By clicking “Find my lo cation” y ou can see the p ermission dialog that your browser uses to obtain your express consent and, on giving your p ermission, you can see all the information that your browser returns ab out your lo cation. The amount and accuracy of data will depend on y our bro wser, ho w it obtains your lo cation and where y ou are. At different times, your bro wser might return location data with accuracy to 20,000 meters or to 20 meters. 9 F uture Dev elopmen ts The W3C Geolo cation API is only one example of how potentially sensitive p ersonal information is made a v ailable on the W eb. The current trend to wards increasingly capable mobile devices and the mobile W eb suggests that these priv acy issues will become increasingly common and imp ortan t in the near future. F or example, the BONDI 22 initiativ e standardizes a set of access tec hnologies for mobile devices whic h go w ell b ey ond just lo cation, including access to address b o oks and calendar information. Mobile devices typi- cally con tain substan tial priv ate information, and the small form factor makes it challenging to design and implemen t complex access control and management interfaces. In the W3C, the Devic e APIs and Policy Working Gr oup (DAP) 23 is tasked with addressing these c hal- lenges. The group’s mission is “to create client-side APIs that enable the developmen t of W eb Applications and W eb Widgets that in teract with devices services suc h as Calendar, Con tacts, Camera, etc.” and to “pro duce a framework for the expression of security p olicies that gov ern access to securit y-critical APIs.” The w orking group has not yet p ro duced an y public do cumen ts, but members ha v e made it clear that they’re closely following the discussion of priv acy in the Geolo cation API as they consider a broader set of APIs. 24 The details of the W3C Geolo cation API and its priv acy supp ort may also affect law and regulation. The F e der al T r ade Commission (FTC) has expressed interest in the p otential harms to consumer priv acy that can arise from mobile devices and lo cation-based services as part of its recen t “Exploring Priv acy” roundtable series. 25 Mean while, the House Committe e on Ener gy and Commer c e recently held a hearing on “The Collection and Use of Lo cation Information for Commercial Purp oses” which may inform broad 22 http://bondi.omtp.org/ 23 http://www.w3.org/2009/dap/ 24 http://lists.w3.org/Archives/Public/public- geolocation/2010Jan/0002.html 25 http://www.ftc.gov/bcp/workshops/privacyroundtables/ F ebruary 2010 13 of 17 UC Berkeley School of Information Rep ort 2010-038 Priv acy Issues of the W3C Geolocation API federal priv acy legislation. Both the FTC and Congress are lik ely to tak e current practices and any industry self-regulation into account when determining whether additional regulation or legislation is necessary . Figuring out where is b est to address priv acy concerns — in specifications, implemen tations, in terfaces, corp orate p olicies or laws — will b e of the utmost imp ortance. User adoption of lo cation-based services may b e slo wed if priv acy issues are not appropriately considered. 10 Recommendations In conclusion, we prop ose four mo difications to the W3C Geolo cation API to enable supp ort of the different principles in our priv acy framew ork that app ear to b e lac king in curren t implementations. 1. Any functionalit y that would enable minimization is notably absent from the sp ecification and as a result users must alwa ys risk transmitting their precise latitude and longitude lo cation. This increases user risk (of physical harm and of revealing sensitive or p ersonally-iden tifying information) while in man y cases not pro viding an y useful adv antage. The specification could either pro vide a standard for differen t levels of gran ularity (p erhaps a subset of RFC4119’s civic lo cation format) which user agen ts could exp ose as a c hoice to users or add a parameter for “fuzzing” latitude and longitude co ordinates b y a user-specified amoun t. 2. The sp ecification wisely uses a mo del of user c onsent and c ontr ol for rev ealing lo cation information — lo cation-based services emplo y a wide v ariet y of metho ds for ho w they request, store and distribute user data and the sp ecification should not inhibit this v ariety . But the mo del relies on web sites proactively informing users of how they will use, retain and distribute user data and our preliminary exploration sho ws that web sites consistently fail to do this. Rather than relying on a p oten tially cumbersome legislativ e solution to enforce notice, functional requirements could b e added to the curren t sp ecification to allow mac hine- and human-readable notices to b e sent along with each request for user lo cation. This would require web sites to explicitly comm unicate (at the time of request) to users ab out use , distribution and r etention and, w e b eliev e, would increase user con trol b y creating informed consen t. Appr opriateness will alwa ys hav e to b e judged on a case-by-case basis, but by providing users with a human-readable explanation of how their information will b e used at least pro vides users with the necessary context to make that decision for themselves. Alternativ ely , the sp ecification could (as in the Geopriv sp ecification) supp ort tw o-wa y communication ab out priv acy rules. Allo wing users to attac h priv acy rules to their own lo cation information may lessen the burden on notice and consent pro cesses which can b e particularly burdensome giv en the form factor of mobile devices and the time-sensitive nature of man y lo cation-based queries. 3. In man y cases the distribution flows of information through the Geolo cation API are opaque to the user: users are rarely aw are of what exactly their lo cation data consists of, where it’s re-transmitted or ev en, in the case of persisted p ermissions, if and when it’s sen t at all. User preferences ma y c hange o v er time even when the information practices of a particular service are completely constant. By b etter supp orting tr ansp ar ency and fe e db ack , the API could resp ond to this con textual asp ect of priv acy . Since curren t user agent implemen tations hav e chosen not to follo w the non-binding advice to enable a wareness of lo cation sharing, the specification could require that w eb bro wsers, where p ossible, pro vide an unobtrusiv e am bien t notice. F urther, the W orking Group could learn from the handful of requesting w eb sites that to da y let the user insp ect their o wn lo cation information (with or without reverse geo coding) and recommend that web browsers provide that same functionalit y and control for all the sites their users visit. F ebruary 2010 14 of 17 UC Berkeley School of Information Rep ort 2010-038 Priv acy Issues of the W3C Geolocation API 4. Although the sp ecification is (and should remain) agnostic to the user agent’s particular lo cation pro vider, it should not ignore the significant risks of aggr e gation among a small num b er of lo cation pro viders (curren tly , Skyho ok Wireless and Go ogle). User agents should be encouraged to provide c hoice betw een different lo cation providers and required to provide information to users on who their lo cation pro vider is and what its priv acy p olicy is. 26 References [1] Kim Alexander and Keith Mills . V oter Priv acy in the Digital Age, Ma y 2004. [2] Ir win Al tman . Priv acy Regulation: Culturally Univ ersal or Culturally Sp ecific? Journal of So cial Issues , 33(3):66–84, 1977. [3] Richard Barnes , Ma tthew Lepinski , Alissa Cooper , John Morris , Hannes Tschofenig , and Henning Schulzrinne . An Architecture for Lo cation and Lo cation Priv acy in In ternet Appli- cations. In ternet Draft draft-barnes-geopriv-lo-sec-05, July 2009. [4] Victoria Bellotti and Abigail Sellen . Design for Priv acy in Ubiquitous Computing En viron- men ts. In Giorgio de Michelis , Carla Simone , and Kjeld Schmidt , editors, Thir d Eur op e an Confer enc e on Computer-Supp orte d Co op er ative Work , pages 77–92, Milano, Italy , September 1993. Klu wer Academic Publishers. [5] Da vid D. Clark , John Wrocla wski , Karen R. Sollins , and Rober t Braden . T ussle in Cyb erspace: Defining T omorrow’s In ternet. In A CM SIGCOMM 2002 Confer enc e on Applic ations, T e chnolo gies, Ar chite ctur es, and Pr oto c ols for Computer Communic ation , pages 347–356, Pittsburgh, P ennsylv ania, August 2002. ACM Press. [6] Julie E. Cohen . Structural Righ ts in Priv acy . University of Chic ago L aw R eview , 75(1), 2008. [7] Sunny Consol vo , Ian E. Smith , T ara Ma tthews , Anthony LaMarca , Jason T aber t , and P auline Powledge . Location Disclosure to So cial Relations: Wh y , When, & What People W ant to Share. In Katz et al. [16], pages 81–90. [8] Lorrie F aith Cranor . Web Privacy with P3P . O’Reilly & Associates, Sebastop ol, California, Septem b er 2002. [9] Lorrie F aith Cranor and Joseph M. Reagle . Designing a So cial Proto col: Lessons Learned from the Platform for Priv acy Preferences. W orld Wide W eb Consortium, Note NOTE-TPR C-970930, No vem b er 1997. [10] Jorge R. Cuellar , John B. Morris , Deirdre K. Mulligan , Jon Peterson , and James M. Polk . Geopriv Requirements. Internet RFC 3693, F ebruary 2004. [11] Andrew Da viel , Felix A. K ¨ agi , and Mar tin Kof ahl . Geographic Extensions for HTTP T rans- actions. In ternet Draft draft-da viel-http-geo-header-05, December 2007. [12] Michelle Engelhardt Danley , Deirdre K. Mulligan , John B. Morris , and Jon Peterson . Threat Analysis of the Geopriv Protocol. Internet RF C 3694, F ebruary 2004. 26 Firefox already do es an excellent job of the latter, explaining in clear terms how the API works and what information is transmitted to Google. See http://www.mozilla.com/en- US/firefox/geolocation/ . F ebruary 2010 15 of 17 UC Berkeley School of Information Rep ort 2010-038 Priv acy Issues of the W3C Geolocation API [13] Mar y Flanagan , D aniel C. Howe , and Helen Nissenbaum . Embo dying V alues in T ec hnol- ogy: Theory and Practice. In Jeroen v an den Hoven and John Wecker t , editors, Information T e chnolo gy and Mor al Philosophy , chapter 16, pages 322–353. Cam bridge Universit y Press, Marc h 2008. [14] Joshua Gomez , Tra vis Pinnick , and Ashkan Sol t ani . KnowPriv acy . T echnical Rep ort 2009-037, Sc ho ol of Information, UC Berkeley, Berk eley , California, Octob er 2009. [15] Ian Hickson and Da vid Hy a tt . HTML 5 — A V o cabulary and Asso ciated APIs for HTML and XHTML. W orld Wide W eb Consortium, W orking Draft WD-html5-20090825, August 2009. [16] Ir vin R. Ka tz , Rober t L. Mack , Linn Marks , Mar y Beth Rosson , and Jak ob Nielsen , editors. CHI ’95: ACM Confer enc e on Human F actors and Computing Systems , Den ver, Colorado, Ma y 1995. A CM Press. [17] Jennifer King and Chris Ja y Hoofnagle . A Superma jority of Californians Supp orts Limits on La w Enforcemen t Access to Cell Phone Lo cation Information. T ec hnical report, School of Law, UC Berk eley, Berkeley , California, April 2008. [18] Balachander Krishnamur thy and Craig E. Wills . Priv acy Diffusion on the W eb: A Longi- tudinal Perspective. In Juan Quemad a , Gonzalo Le ´ on , Yo ¨ elle S. Maarek , and W olfgang Nejdl , editors, 18th International World Wide Web Confer enc e , pages 541–550, Madrid, Spain, April 2009. ACM Press. [19] Da vid M. Kristol . HTTP Cookies: Standards, Priv acy , and Politics. ACM T r ansactions on Internet T e chnolo gy , 1(2):151–198, No v em b er 2001. [20] Alexander Ma yrhofer and Christian Sp anring . A Uniform Resource Identifier for Geographic Lo cations (’geo’ URI). Internet Draft draft-ietf-geopriv-geo-uri-04, No vem b er 2009. [21] John Morris and Alan D a vidson . Policy Impact Assessments: Considering the Public Interest in In ternet Standards Dev elopmen t, August 2003. [22] Deirdre K. Mulligan and Aaron Burstein . Implemen ting Copyrigh t Limitations in Rights Expression Languages. In 2003 A CM Workshop on Digital R ights Management , volume 2696 of L e ctur e Notes in Computer Scienc e , pages 137–154, W ashington, D.C., Nov em b er 2003. Springer- V erlag. [23] Helen Nissenbaum . Priv acy as Contextual In tegrit y . Washington L aw R eview , 79(1), 2004. [24] Organisa tion for Economic Co-Opera tion and Development (OECD) . Guidelines on the Protection of Priv acy and T ransb order Flows of Personal Data, August 1980. [25] Leysia P alen and P aul Dourish . Unpac king ’Priv acy’ for a Net w ork ed W orld. In Gilber t Cockton and P anu K orhonen , editors, Confer enc e on Human F actors and Computing Systems (CHI 2003) , pages 129–136, F ort Lauderdale, Florida, April 2003. ACM Press. [26] Sameer P a til and Jennifer Lai . Who Gets to Know What When: Configuring Priv acy Permissions in an Aw areness Application. In Katz et al. [16], pages 101–110. [27] Andrei Popescu . Geolo cation API Sp ecification. W orld Wide W eb Consortium, W orking Draft WD-geolo cation-API-20090707, July 2009. [28] Harr y Surden . Structural Rights in Priv acy . SMU L aw R eview , 60:1605–1629, 2007. F ebruary 2010 16 of 17 UC Berkeley School of Information Rep ort 2010-038 Priv acy Issues of the W3C Geolocation API [29] Janice Y. Tsai , P a trick Kelley , P aul Drielsma , Lorrie F aith Cranor , Jason Hong , and Norman Sadeh . Who’s Viewed Y ou?: The Impact of F eedback in a Mobile Location-Sharing Ap- plication. In Dan R. Olsen , Richard B. Ar thur , Ken Hinckley , Meredith Ringel Morris , Scott E. Hudson , and Saul Greenberg , editors, 2009 Confer enc e on Human F actors in Com- puting Systems (CHI 2009) , pages 2003–2012, Boston, Massac husetts, April 2009. A CM Press. [30] United St a tes Code . Drivers Priv acy Protection Act (DPP A). 18 USC 2721, January 2009. F ebruary 2010 17 of 17