Battery Status Not Included: Assessing Privacy in Web Standards Lukasz Olejnik Steven Englehardt Arvind Narayanan University College London Princeton University Princeton University lukasz.w3c@gmail.com ste@cs.princeton.edu arvindn@cs.princeton.edu http://lukaszolejnik.com http://senglehardt.com http://randomwalker.info Abstract—The standardization process is core to the develop- during the development of internet protocols [1]. The W3C ment of the open web. Until 2013, the process rarely included pri- has also invested considerable resources into the creation of vacy review and had no formal privacy requirements. But today specialized methodologies for such privacy assessments [2], the importance of privacy engineering has become apparent to standards bodies such as the W3C as well as to browser vendors. [3]. This includes taking public stances on privacy expectations Standards groups now have guidelines for privacy assessments, [4] and defining new groups and processes to evaluate privacy and are including privacy reviews in many new specifications. [5], [6], [7]. Even the frameworks used during specification, However, the standards community does not yet have much development, and publishing have been updated to encourage practical experience in assessing privacy. all specification authors to include privacy and security review In this paper we systematically analyze the W3C Battery Status API to help inform future privacy assessments. We begin sections [8], [9]. by reviewing its evolution — the initial specification, which only These recent advances in privacy review are timely, as new cursorily addressed privacy, the discovery of surprising privacy and proposed web features will provide websites with much vulnerabilities as well as actual misuse in the wild, followed deeper access to the user’s device and environment, especially by the removal of the API from major browser engines, an on smartphones and Internet-of-Things (IoT) devices. Ex- unprecedented move. Next, we analyze web measurement data from late 2016 and confirm that the majority of scripts used the amples include Bluetooth connectivity [10], low-level device API for fingerprinting. Finally, we draw lessons from this affair sensors such as ambient light, acceleration, and vibration [11], and make recommendations for improving privacy engineering [12], and even the user’s interpupillary distance, in the context of web standards. of Virtual Reality [13]. But why should standards consider privacy at all, rather I. I NTRODUCTION than leave it to browser vendors? Perhaps the market will The Battery Status API offers an interesting and unusual then allow each user to choose a browser that provides his case study of privacy assessment in the web standardization or her preferred trade-off between privacy and functionality. process. The specification started with a typical progression: This argument is beguiling but simplistic — standards must fix it went through a few iterations as a draft, was quickly imple- many design choices to ensure interoperability, and some of mented by multiple browser vendors, and then progressed to these will inevitably impact privacy [1]. Indeed, there are many a candidate recommendation — one which characterized the examples of standards that impede efforts by browser vendors privacy impact as “minimal”. Several years later, after it was to improve privacy without causing breakage [14]. Further, implemented in all major browser engines and was nearing standards allow setting a privacy floor across implementations. finalization, researchers discovered several privacy vulnerabil- This helps avoid a race to the bottom, considering that privacy ities as well as misuse in the wild. In an unprecedented move, might be a “market for lemons” [15] and is susceptible to two of the three major browser engines removed support for numerous behavioral biases [16]. the API and another browser moved to an opt-in model. In this In this paper we study the privacy engineering aspects [17] paper, authored by several of the researchers who discovered of the Battery Status API, with a focus on the standardization the privacy problems, we reflect on these events, present new and implementation process. Specifically, empirical evidence of misuse, and extract recommendations 1) We conduct a systematic case study of the Battery Status for privacy reviews in future standards. API (Section III). Before 2013, there were no formal review processes at 2) We provide new measurements of Battery Status API the major standards bodies to address privacy during the use on the web (Section IV). design and standardization of web features. This is reflected 3) We extract useful privacy engineering practices and in the lack of privacy or security considerations in many past provide recommendations to improve the design process specifications. However, the standards community has recently (Section V). made numerous substantial changes to address privacy during We hope our work will be useful to standardization bodies, the early stages of feature development. In 2013 the IETF browser vendors, privacy engineers, researchers, and web de- formally defined recommendations for privacy assessments velopers. We seek to enrich Privacy Impact Assessment (PIA) methodologies, with possible applications to other domains and Flash storage to respawn cleared identifiers [19], [20], including IoT and mobile APIs. [21], [22], using “enriched” headers that contain tracking IDs injected by ISPs [23], and by identifying a device solely by its II. BACKGROUND AND R ELATED W ORK properties, i.e. device fingerprinting [24], [25], [26], [27]. The The W3C standardization process. The W3C employs W3C’s TAG has identified these advanced tracking behaviours a maturity level model in the standardization process [18]. as “actively harmful to the Web, because [they are] not under Specifications start as a community group Working Draft and the control of users and not transparent” [4]. may undergo several revisions while the scope and content is In this case study, we examine how the Battery Status API refined. Once the specification is ready for a final review by can be used to fingerprint devices (Section III-C). Device a wide audience, it will progress to a Candidate Recommen- fingerprinting is the process of identifying a device by its set dation. The W3C formally calls for implementations at this of features, rather than by setting a persistent identifier on the stage, although in practice they may already exist. Feedback device. The effectiveness of tracking increases as a device’s from the Candidate Recommendation and experience gathered feature set is more unique. Past studies have demonstrated from implementations is used to refine the specification further. that a majority of both desktop and mobile users have a If the specification requires no substantive changes it will unique fingerprint [28], [29]. In response to fingerprinting progress to a Proposed Recommendation. After a final set concerns, the W3C’s PING released a Working Group Note to of endorsements a specification will progress to a full W3C provide guidance to specification authors on how to address Recommendation. and mitigate fingerprinting in their specifications [30]. The lengthy standardization process is consensus-driven. When data is identified as potentially sensitive, such as that The stakeholders of a standard are generally organized into which relates to the user’s device, behavior, location, or en- Working Groups, typically comprised of employees of browser vironment, various W3C specifications have applied different vendors and other technology companies. To reach consen- restrictions on access to that data. Some specifications have sus, all members must agree on a decision. Other Working made the data available only in the top level browsing context Groups, such as those specializing in privacy, accessibility, (i.e. where access from third-party scripts is limited) [31], or web architecture may give their input on aspects of the and others provide data only in a secure context (i.e. among specification relevant to their mission. Additionally, the speci- other restrictions, requiring TLS) [32]. This type of data access fication Working Group must provide evidence of wide review, also frequently requires user permission before any potentially which includes reviews by a number of external parties: the sensitive information is made available. The Web Permissions public (i.e. researchers) and NGOs (some of whom are W3C API is a draft specification of a mechanism that allows users members). to manage these types of permissions in a user-friendly way Privacy reviews often happen during the draft stage, al- [33]. though the depth of reviews can vary. As of 2017, the official Past privacy assessment research. Several studies have W3C Process Document [18] does not require a privacy examined how privacy assessments are conducted as part of review. In practice, reviews are often performed prior to a the specification process. Nick Doty identifies and addressees draft entering the Candidate Recommendation level. A privacy the challenges of privacy reviews in standardization bodies consideration section can be normative, in which the state- [2]. Doty describes the history of security and privacy con- ments included are requirements that an implementation must sideration sections in Request for Comments (RFC), IETF follow to be compliant with the specification. Alternatively, specifications, and W3C specifications. RFC 6973 describes the section can be non-normative, which is used to provide how design choices in internet protocols may impact privacy, extra information, context, or recommendations that an imple- and provides guidelines for drafting of Privacy Considerations mentation is not required to adhere to. sections in RFC documents [1]. Similarly, Frank Dawson The W3C’s Technical Architecture Group (TAG), which describes a methodology for drafting the privacy considera- aims to build consensus on principles of web architecture, tions sections of W3C standards [3]. Dawson highlights the authored the Security and Privacy Self-Review Questionnaire importance of privacy assessments during each stage of a draft [7]. The questionnaire exists to help authors, TAG, and others specification and the need for an open process to incorporate assess the privacy and security impacts of a specification. the findings of external research. It recommends that authors review their specifications under III. C ASE STUDY: BATTERY S TATUS API several different threat models and asks a series of questions related to data access and quality. The W3C also has the A. API specification Privacy Interest Group (PING), which provides guidance and The Battery Status API is a browser mechanism that pro- advice for addressing privacy in standards [5]. vides access to the power management information of a device W3C privacy assessment practices and requirements. [34]. An example use case listed in the W3C specification Privacy reviews in specifications often focus on how the pro- is responding to low battery levels. For instance, an online posed design impacts web tracking. Past studies have shown word processor might auto-save more frequently when the that trackers frequently use many browser technologies to track battery is low. The API provides the following information: users: by using stateful mechanisms like cookies, localStorage, the battery charge level (e.g. 0.43 when the battery has 43% Firefox adds Firefox 38 rounding Chrome rounding Blink bug moved to support bug fixed patch commit permissions component W3C Battery WebKit adds Firefox rounding W3C Yandex announces Status Event WD support bug reported Prop.Rec. opt-in model 2011 2012 2013 2014 2015 2016 2017 Chrome adds API misuse Firefox 52 limits support in the wild API to internal use W3C Battery W3C Candidate Leaking Battery Uber Firefox and WebKit Status API WD Recommendation report published study remove support Fig. 1: Timeline of events. remaining power), the charging status (whether or not the Battery status readouts made users of certain platforms device is charging), the time in seconds to a full discharge vulnerable to tracking across sites by a third-party. The (dischargingTime; when discharging) or a full charge API’s charge level returns a value between 0 and 1 which (chargingTime; when charging). represents the ratio of the current charge remaining to the In April 2011, the Battery Status Event Working Draft maximum capacity. The researchers found that Firefox on first described how a website can access battery information Linux returned a double-precision floating-point value for [35]. The specification was reworked into the Battery Status charge level, the result of returning the operating system’s API in November 2011 [36] and progressed to a Candidate value directly without truncating the result. This means that Recommendation in May 2012 [37]. This version identified a there is a large number of possible values for the charge “minimal impact on privacy or fingerprinting”, but suggested level. Thus, if a tracker were to see the same charge level “the user agent can obfuscate the exposed value in a way readout on two different sites at the same instant (or within that [websites] cannot directly know if a hosting device has a short time window), it gives the tracker evidence that the no battery, is charging or is exposing fake values.” [38]. This page visits were from the same device. This is true even if the shows that although the specification authors felt the privacy user cleared cookies between the two visits or used different impact was minimal, they felt there was enough of a risk that browser contexts for the two visits, such as regular versus user agents (browsers) may want to hide a user’s true battery private browsing. status. The researchers further pointed out that short-term tracking B. Adoption by browser vendors was possible even on platforms which didn’t expose the high- The first implementations of the Battery Status API were precision charge level, although it was less effective. On in 2012 by Firefox [39] (mobile and desktop) and WebKit platforms other than Firefox on Linux, the battery charge level [40]. Chrome1 also started an implementation in 2012 that was just two significant digits. However, by combining the was never completed, citing a general lack of interest and charge level with dischargeTime and chargeTime the convincing use cases [41]. Chrome later removed and re- researchers estimated the possible number of states to be on implemented it in 2014 on both mobile and desktop [41]. the order of millions under normal operating conditions. Thus, Other browsers based on Chrome’s Blink engine supported a tracker could still conclude that two page visits with the the API soon after, such as Opera in 2014 [42]. This level same status readout is likely the same device, particularly if of implementation fulfills W3C requirements of having at at it coupled that measurement with the device’s IP address. least two independent implementations prior to finalization of a specification [18]. For a summary of support by additional Finally, the researchers showed that the double-precision browsers, see Table I. readouts for Firefox on Linux enabled a more sophisticated attack in which a site could recover the battery capacity. C. Discovery of privacy vulnerabilities The attack works by reading the device’s current charge level In 2015 Olejnik et al. [43] examined the W3C specification and calculating which possible battery capacities could result and the browser implementations of the API and found several in that charge level based on how the underlying operating privacy vulnerabilities. They showed that the API can be used system battery library calculates charge level. As the tracker to track users, both by using the status readouts as short-term makes more readings, it decreases the number of possible identifiers and by using repeated readouts to reconstruct the battery capacity values that could result in the observed battery capacity on certain platforms. sequence of charge levels. In the end, a tracker could recover 1 Chromium and Chrome are both based on the Blink rendering engine and the actual battery capacity, and use that as a static identifier expose the same Battery Status API. We refer exclusively to Chrome for the for the device. This capacity could also be included alongside remainder of the paper but our analysis is applicable to both browsers. other device properties in a broader device fingerprint. D. Initial privacy improvements by browser vendors prices for users with a low battery level [48], [49]. Mozilla In response to the 2015 report [43], Firefox fixed the cited these second order privacy concerns on W3C mailing precision of the battery level readout to two significant digits lists during their initial discussions of whether to remove or for all platforms [44]. Chrome did not return high precision restrict the API [50]. Materials obtained in a Subject Access readouts on Linux because of an implementation difference. Request confirm that Uber indeed collects the device battery However, had Chrome used a high precision source it would level for use in fraud detection [51]. have exhibited the same behavior. To prevent this, Chrome G. Removal of the API from browsers preemptively capped the precision to no more than 2 digits As summarized in Table I, support for the Battery Status on all platforms [45]. The W3C specification was amended API has tumbled in response to privacy concerns. At its peak [46] with non-normative privacy recommendations. Notable in 2016, the API was implemented in the engines supporting additions are: Firefox, Chrome, and Safari (though it was disabled in Safari). 1) data minimization — avoiding the exposition of high In addition, other browsers built on the major engines, such precision readings of battery status information as Opera and the Yandex Browser, also exposed the API to 2) user control — optionally making the API subject to the web. browser permissions that may require prompting the user In October 2016 Mozilla announced it would remove access prior to the use of the API to API by web content in Firefox 52 [59]. The API is now 3) incognito support — disabling the API in private brows- restricted to internal browser code, and may eventually be ing modes exposed to WebExtensions-based browser extensions [52]. In 4) transparency — informing the user when the API is and March 2017 Firefox 52 was released with the API removed has been in use [53]. Following Mozilla’s decision, WebKit, the underlying This response prevents the battery capacity from being engine behind Safari browser, removed the Battery Status API recoverable and lessens the usefulness of status readouts as from its source tree [54]. a short-term identifiers. However, even with reduced precision As of March 2017, Chrome developers have not provided an the battery status output will still provide additional identifying official stance on whether or how they will change the API. information that can be used to fingerprint and re-identify a It is possible they are considering placing it behind a user device over short time intervals. permission, as evidenced by the choice of bug component3 for the relevant bug [55]. Microsoft Edge continues to have E. Discovery of misuse on the web the API on its feature wishlist [56]; as of March 2017 there Englehardt and Narayanan measured the prevalence of is no indication of a change. tracking and fingerprinting techniques on the Alexa top 1 Other browsers based on these engines could also restrict million websites in January 2016 [27]. During manual exami- access to the API if desired. One such example is the Yandex nation of automatically identified fingerprinting scripts, they Browser (built on the Blink engine), which now spoofs a found two scripts, together present on 22 sites, that used fully charged status until the user explicitly enables the API battery status as part of a device fingerprint. This finding using the appropriate browser setting [58]. Yandex has limited confirmed that battery status was being used to fingerprint market share, but we include it in the table to show the devices in the wild. In Section IV we present an automated versatility of responses by browser vendors. analysis of the Alexa top 50,000 to audit the use of the API Browser vendors regularly make privacy-related changes in late 2016. and continually deprecate unused and insecure features. How- One script, served by lynxbroker.de, retrieves only the cur- ever, the removal of an entire API in response to privacy rent charge level of the device. The other script, served by ad- concerns is unprecedented. We verified that this type of feature score.com, queries all properties of the BatteryManager removal has not happened before by checking a website which interface, including the current charging status, the charge tracks browser changes for compatibility purposes4 . level, and the time remaining to discharge or recharge. Both scripts combine the retrieved battery information with other H. The future of the API identifying properties of the device, such as the canvas finger- As of March 2017, it is unclear how the specification and print2 or system fonts, to create a device fingerprint. remaining implementations will progress. Since the API was implemented in both Chrome and Firefox in 2016, it fulfilled F. Discovery of second-order privacy concerns the W3C requirement of two interoperable implementations Until May 2016, the primary privacy concern of the API was [18]. Thus, despite only having one current implementation its usefulness for online tracking. In May 2016, Uber disclosed in 2017 (i.e. Chrome), the specification could progress to a its finding that users with a low battery are more willing to pay W3C Recommendation. If there isn’t sufficient interest by higher prices for a ride (i.e. more likely to book a ride during the authors to continue the specification, it can be published surge pricing) [47]. This sparked concerns that Uber or other as a W3C Note, which would signify the end of active companies could misuse battery status information to increase 3 Blink > Permissions API 2 For a description of canvas fingerprinting see [26] 4 www.fxsitecompat.com Browser Engine API Support (2016) Current API Support (2017) Firefox Gecko Initial support since version 10 [39] Inaccessible to web content [52] [53] Safari WebKit Not enabled. WebKit support since 2012 [40] WebKit removed [54] Chrome Blink Supported since version 38 [41] Permissions under consideration [55] Edge EdgeHTML Not supported. Considered [56] Not supported. Considered [56] Yandex Blink Supported Spoofing by default, opt-in [57], [58] TABLE I: API support in various browsers and privacy strategies employed. development by the W3C. The specification authors have the charging state, the charge level, and time to discharge (or suggested restricting access to the API to secure, top-level charge). In addition to battery information the scripts collect browsing contexts as an additional step to the privacy risks the number of CPU cores, the JS console heap size, the in-use associated with the API [60]. console heap size, and the total console heap size. We found Riskified scripts utilitizing the Battery Status IV. U SE AND MISUSE OF THE API IN THE WILD API on 27 of the top 50,000 sites measured. Among the A. Statistics on usage in the wild notable sites embedding Riskified were burberry.com (a pop- We measured the use of the Battery Status API on the ular clothing fashion brand). Additionally, we queried the homepages of the Alexa top 50,000 sites in November 20165 Princeton Web Census data for November 2016 [27] and using OpenWPM [27]. We found that in total, the API was found that 205 of the top 1 million sites request the same used by 56 distinct parties on 841 sites. The majority of this Riskified script. Riskified receives the data with requests to usage was by third parties — 33 third parties on a total of 815 https:// c.riskified.com/ client infos.json. sites. C. A retrospective look at vendor response We manually classified these 33 scripts, all distinct, to determine how the feature was being used around the time Nearly half of the Battery Status API use we classified of its removal. We build on the fingerprinting classification was for user profiling or identification — a use case the API methodology outlined in [27]. We classify a script as benign if designers did not intend to support. When measured in terms it uses the battery status to do things we feel the API designers of distinct scripts rather than distinct sites, that fraction rises to intended to support, such as performance and diagnostic mea- two-thirds. Note that our measurement is conservative; parties surements. We classify a script as tracking if it uses the API which collect battery status information through performance for device identification, whether for fingerprinting, analytics, or feature detection libraries can also use that information to or fraud detection. track users, but we do not make this assumption. We found 16 third parties using the API for tracking, 11 of At the time of Firefox’s and WebKit’s decisions to remove which use it as part of a device fingerprint. An additional the API, the preliminary evidence suggested that it was being 8 third parties use the API for benign purposes. For the misused in the majority of cases [61]. Mozilla’s discussion remaining 9 third parties, we were unable to classify the usage, thread cites two specific uses: the research described in either due to script obfuscation or vagueness. Scripts from the Section III and the Boomerang performance library [61]. The 16 trackers are present on 347 sites (or around 48% of sites empirical data presented here suggest that use is indeed split on which we classified API use). The benign uses of the API between gathering performance metrics and tracking users. We were primarily from two third parties: YouTube, where the found no additional categories of use, and confirm that the API was used in performance metrics for embedded videos, examples presented in the discussion thread reflect the broader and Boomerang6 , a performance measurement library. usage on the web. B. A representative example of misuse V. L ESSONS L EARNED & R ECOMMENDATIONS A representative third-party script using the Battery Status Based on insights from our case study, we extract a set of API for tracking is a beacon script7 served by riskified.com, a good privacy engineering practices and make several concrete supplier of fraud prevention solutions for e-commerce systems. recommendations on how standards bodies can improve the Riskified’s marketing material maintains that the company standardization process. We draw from our research, our takes advantage of user behavioral monitoring models. participation in standardization efforts, our assessments of Riskified scripts collect a number of behavioral properties specifications in the draft phase, as well as a review and tests of a user’s device. From the Battery Status API, they collect of experimental web browser features. 5 Since Mozilla and WebKit announced their intent to remove the API in A. Information exchange between vendors and researchers is October 2016, it is possible some sites or scripts could have changed their use essential of it in response to that news. We believe a 1 month time window is small enough that this is unlikely to have a significant effect on our results. Research can reveal theoretical privacy risks and their 6 https://soasta.github.io/boomerang/doc/ exploitation in the wild; it can also provide data on the usage 7 Supplied from the URL of the form http[s]://beacon.riskified.com/?shop=... of features on the web. Standards-based platforms such as the web are more conducive to research, and therefore attract often early adopters of a new API [27], [26]. The benefits more of it, compared to proprietary platforms. Further, when of doing an early audit are two-fold: misuses of the API implementations are open-source, knowledge propagates not that weren’t found during the privacy assessment may be just from researchers to vendors but also among vendors. discovered, and any uncovered vulnerability can be fixed at Our case study illustrates these themes and their beneficial the specification level before web compatibility and breakage effects on privacy. After Firefox was reported to return high- become a concern. precision values on Linux (Section III-C), both Firefox and In the past, fingerprinting abuse in the wild has been Chrome fixed the bug. Note that although Chrome did not primarily measured by the academic research community [27], exhibit the vulnerability, it chose to preemptively restrict [26], [24], [25]. As research on fingerprinting starts to lose its the precision of the readout to prevent the possibility. This novelty, academic researchers may lose the incentive for fre- illustrates knowledge propagation between vendors, sparked quent measurements of fingerprinting abuse. As a replacement, by research results. Similarly, the specification was updated we suggest measurement through built-in browser probes or a to include a recommendation to avoid high-precision readouts dedicated web crawling infrastructure run by browser vendors (Section III-D). or privacy advocacy groups. Still, the specification process can benefit from a deeper connection to research. Deliberate attempts to break the pri- D. Specification authors should carry out privacy assessments vacy assumptions of specifications should be actively incen- with multiple threat models tivized — perhaps by funding attack research, or by organizing Our case study shows how a seemingly innocuous mecha- a forum for academics and researchers to publish their privacy nism can introduce privacy risks. The original 2012 specifica- reviews. tion of Battery Status API characterized the fingerprinting risk as “minimal”, but did not include any analysis of that risk [38]. B. The specification process should include a privacy review An enumeration of the possible fingerprinting approaches, of implementations even if minimal in expected effectiveness, may have helped On the modern web, proposed features often get deployed avoid the blind spot. We recommend that if any privacy vulner- rapidly. At the time a specification is drafted, initial imple- ability is identified, possible exploitation should be modeled mentations are typically available in the development versions and analyzed in detail. Privacy assessment methodologies must of browsers. By the time the spec is finalized, several vendors evolve to keep abreast of the growing technical complexity of may already fully support a feature; in fact, the W3C requires web APIs. at least two implementations to exist before official recom- The case study shows the importance of assessing the data mendation. We recommend that specification authors study quality requirements of APIs, as unnecessarily precise data implementations to prepare higher quality privacy assessments. may expose users to unforeseen privacy risks. It also shows the Implementations enable field testing of theoretical attacks and importance of data minimization as a precaution against unex- can be examined for potential API misuses. pected future misuses. Indeed, the Battery Status vulnerability With the Battery Status API, the privacy risk stemmed served as a motivating example of these strategies in a W3C from a difficult-to-predict interconnection of software layers, draft recommendation on browser fingerprint minimization namely the browser acquiring information from the operating [30]. system in order to supply it to a web script. Such a risk is Specification authors must also enumerate and analyze difficult to predict during the design phase, but becomes much all relevant threat models. Some implementers such as the easier to identify with access to an implementation. Tor browser operate under much stricter threat models. For In contrast to the Battery Status API, consider the Ambient example, most implementers may find it acceptable to reveal Light Events API, which provides access to the light level of the user’s operating system through a new API. But not the the device’s surroundings. The specification was examined at Tor Browser, as it attempts to maintain a uniform fingerprint the API design level, the implementation was tested, and the across all devices [64]. source code was reviewed8 — all as part of the review process. E. Avoiding over-specification supports innovative privacy Issues identified at the implementation level led both Chrome solutions and Firefox to address a rounding issue related to the light level data [62], [63]. W3C specifications are expected to be well defined, but do allow implementers significant leeway. We recommend that C. API use in the wild should be audited after implementation standards exploit this flexibility to set a privacy floor yet leave In removing the Battery Status API from Firefox, Mozilla room for innovative privacy solutions by implementers. Over- was influenced by the paucity of legitimate uses of the API in specification may have the unintended effect of rendering some the wild [61]. This underscores the importance of analyzing privacy solutions uninteroperable with the standard or with the early use of an API after deployment. Measurement other web features. studies have continually shown that fingerprinting scripts are Indeed, implementers have employed novel strategies to mitigate the privacy risks of the Battery Status API (Sec- 8 Lukasz Olejnik participated in this effort as a W3C Invited Expert. tion III-G). Yandex, which reports that the battery is fully charged, effectively disables the API by default. A user may R EFERENCES choose to offer websites battery information in an explicit opt-in manner [57]. This opt-in mechanism is also used for [1] A. Cooper, H. Tschofenig, B. Aboba, J. Peterson, J. Morris, M. Hansen, and R. Smith, “Rfc 6973 — privacy considerations for internet proto- the Vibration API [12], possibly addressing potential misuses cols,” IETF, Tech. Rep., 2013. [65], and giving users a consistent privacy control experience [2] N. Doty, “Reviewing for privacy in internet and web standard-setting,” across APIs. In contrast, Firefox removed access to the entire in Security and Privacy Workshops (SPW), 2015 IEEE. IEEE, 2015, pp. 185–192. API from web content, but allowed the API to be accessible [3] F. Dawson, “Specification Privacy Assessment (SPA) ,” https://yrlesru. internally and to addon-sdk extensions. This allows the API to github.io/SPA/, 2013. still be used by privileged code while preventing abuse from [4] M. Nottingham, “Unsanctioned Web Tracking,” https://www.w3.org/ untrusted code. 2001/tag/doc/unsanctioned-tracking/, 2015. [5] “Privacy Interest Group Charter,” https://www.w3.org/2011/07/privacy- F. Specifications should provide guidance for web developers, ig-charter, 2011. [6] “Tracking Protection Working Group Charter,” https://www.w3.org/ not just browser vendors 2011/tracking-protection/charter.html, 2011. Specifications should not only identify points of privacy [7] M. West, “Self-Review Questionnaire: Security and Privacy,” https:// concern for browser vendors and other implementers, but w3ctag.github.io/security-questionnaire/, 2015, accessed: 25.10.15. [8] ——, “Bikeshed should require security and privacy considerations should also provide useful guidance for web application sections,” https://github.com/tabatkins/bikeshed/issues/513, 2015. developers when possible. Web developers are ultimately [9] N. Doty, “Nudging/warnings/prompts for Privacy and Security Consid- the end consumers of new features and are responsible for erations sections,” https://github.com/w3c/respec/issues/539, 2015. [10] Web Bluetooth Community Group, “Web Bluetooth API,” https:// complying with local data protection regulations. To assist webbluetoothcg.github.io/web-bluetooth/, 2017. these developers, specifications should highlight if a particular [11] T. Langel and R. Waldron, “Generic Sensors API,” https://www.w3.org/ feature provides sensitive data. Including this information in TR/generic-sensor/, 2017. a specification will also assist browser vendors in properly [12] A. Kostiainen, “Vibration API,” https://www.w3.org/TR/vibration/, 2016. documenting the APIs. [13] W3C, “WebVR,” https://w3c.github.io/webvr/spec/1.1/, 2017. The Battery Status API specification currently contains [14] Y. Zhu, “Clarify section 3.14 and add Third Party Tracking as an guidance describing the possible risks and suggesting mitiga- opt-in threat model,” https://github.com/w3ctag/security-questionnaire/ issues/7, 2015. tion strategies (Section III-D). It is one of the sensor APIs [15] T. Vila, R. Greenstadt, and D. Molnar, “Why we can’t be bothered maintained by W3C’s Device and Sensors Working Group to read privacy policies models of privacy economics as a lemons [66]. Other sensor APIs have richer data sources and may pose market,” in Proceedings of the 5th international conference on Electronic commerce. ACM, 2003, pp. 403–407. more complex privacy threats, making it crucial to provide [16] A. Acquisti and J. Grossklags, “What can behavioral economics teach guidance for developers. For example, draft specifications us about privacy,” Digital Privacy: Theory, Technologies and Practices, of the Generic Sensors API [11] and the Web Bluetooth vol. 18, pp. 363–377, 2007. API [10] recommend that web developers perform a privacy [17] S. Gürses and J. M. del Alamo, “Privacy engineering: Shaping an emerging field of research and practice,” IEEE Security & Privacy, impact assessment prior to deploying applications which make vol. 14, no. 2, pp. 40–46, 2016. use of these APIs. We commend these authors for attending [18] “W3C Technical Report Development Process ,” https://www.w3.org/ to privacy, but call for such specifications to include more 2017/Process-20170301/#Reports, accessed 10.02.16. [19] H. C. Altaweel I, Good N, “Web privacy census,” Technology Science, detailed recommendations. 2015. [Online]. Available: http://techscience.org/a/2015121502 VI. C ONCLUSION [20] A. Soltani, S. Canty, Q. Mayo, L. Thomas, and C. J. Hoofnagle, “Flash cookies and privacy.” in AAAI Spring Symposium: Intelligent The removal of an entire browser feature by multiple Information Privacy Management, 2010. vendors in response to privacy concerns is an unprecedented [21] M. Ayenson, D. J. Wambach, A. Soltani, N. Good, and C. J. Hoofnagle, “Flash cookies and privacy II: Now with HTML5 and ETag respawning,” decision. It underscores the importance of engineering for World Wide Web Internet And Web Information Systems, 2011. privacy throughout the specification, implementation, and web [22] A. M. McDonald and L. F. Cranor, “Survey of the use of Adobe Flash development stages. Local Shared Objects to respawn HTTP cookies, a,” ISJLP, vol. 7, 2011. [23] J. Mayer, “The Turn-Verizon Zombie Cookie,” http://webpolicy.org/ Our work highlights how privacy research can influence 2015/01/14/turn-verizon-zombie-cookie/, 2015. standards and implementations. We hope that our case study [24] N. Nikiforakis, A. Kapravelos, W. Joosen, C. Kruegel, F. Piessens, and and recommendations will prove useful to standards bodies, G. Vigna, “Cookieless monster: Exploring the ecosystem of web-based browser vendors, and web developers. We also hope that pri- device fingerprinting,” in Security and Privacy (S&P). IEEE, 2013. [25] G. Acar, M. Juarez, N. Nikiforakis, C. Diaz, S. Gürses, F. Piessens, vacy impact assessment and other sound privacy engineering and B. Preneel, “FPDetective: dusting the web for fingerprinters,” in practices will make inroads into nascent domains such as the Proceedings of CCS. ACM, 2013. Internet of Things. [26] G. Acar, C. Eubank, S. Englehardt, M. Juarez, A. Narayanan, and C. Diaz, “The web never forgets: Persistent tracking mechanisms in ACKNOWLEDGMENTS the wild,” in Proceedings of CCS, 2014. [27] S. Englehardt and A. Narayanan, “Online tracking: A 1-million-site We would like to thank Hadley Beeman (W3C TAG), Mar- measurement and analysis,” in Proceedings of the 2016 ACM SIGSAC cos Caceres (Mozilla) and Anssi Konstiainen (Intel) for help Conference on Computer and Communications Security, ser. CCS ’16. and useful feedback. Englehardt and Narayanan are supported New York, NY, USA: ACM, 2016, pp. 1388–1401. [Online]. Available: http://doi.acm.org/10.1145/2976749.2978313 by NSF award CNS 1526353. Measurements were funded with [28] P. Eckersley, “How unique is your web browser?” in Privacy Enhancing an AWS Cloud Credits for Research grant. Technologies. Springer, 2010, pp. 1–18. [29] P. Laperdrix, W. Rudametkin, and B. Baudry, “Beauty and the beast: [62] L. Olejnik, “ Bug 1299454 - Round Off Ambient Light Sen- Diverting modern web browsers to build unique browser fingerprints,” sor event.value ,” https://bugzilla.mozilla.org/show bug.cgi?id=1299454, in 37th IEEE Symposium on Security and Privacy (S&P 2016), 2016. 2016. [30] N. Doty, “Mitigating Browser Fingerprinting in Web Specifications,” [63] Olejnik, Lukasz, “Issue 642731. Round Off Ambient. Light Sen- https://github.com/w3c/fingerprinting-guidance/issues/3, 2015. sor event.value,” https://bugs.chromium.org/p/chromium/issues/detail? [31] “HTML 5.1 W3C Recommendation, 1 November 2016,” https://www. id=642731, 2016. w3.org/TR/html51/browsers.html#top-level-browsing-context, 2016. [64] M. Perry, E. Clark, and S. Murdoch, “The Design and Implementa- [32] Y. Zhu and M. West, “Secure Contexts,” https://www.w3.org/TR/secure- tion of the Tor Browser [DRAFT],” https://www.torproject.org/projects/ contexts/, 2016. torbrowser/design/, 2015. [33] M. Lamouri, M. Cceres, and J. Yaskin, “Permissions API,” https://w3c. [65] “ Issue 507703. Ads using navigator.vibrate,” https://bugs.chromium.org/ github.io/permissions/, 2016, accessed: 15.02.17. p/chromium/issues/detail?id=507703, 2015. [34] A. Kostiainen and M. Lamouri, “Battery Status API,” https://www.w3. [66] “Device and Sensors Working Group,” http://www.w3.org/2009/dap/, org/TR/2016/PR-battery-status-20160329, March 2016. 2009, accessed: 15.02.17. [35] A. Kostiainen, “Battery Status Event Specification,” https://www.w3.org/ TR/2011/WD-battery-status-20110426/, April 2011. [36] ——, “Battery Status API,” https://www.w3.org/TR/2011/WD-battery- status-20111129/, November 2011. [37] A. Kostiainen and M. Lamouri, “Battery Status API,” https://www.w3. org/TR/2012/CR-battery-status-20120508/, May 2012. [38] ——, “Battery Status API,” https://www.w3.org/TR/2014/CR-battery- status-20141209, 2014. [39] Mozilla, “Firefox 10 for developers (release notes) ,” https://developer. mozilla.org/en-US/Firefox/Releases/10, 2012. [40] WebKit, “Changeset 110991. Support for Battery Status API.” https: //trac.webkit.org/changeset/110991, 2012. [41] “Battery Status API,” https://www.chromestatus.com/feature/ 4537134732017664, 2015. [42] Opera, “Opera 26 Release Notes,” https://www.opera.com/docs/ changelogs/unified/2600/, 2014. [43] L. Olejnik, G. Acar, C. Castelluccia, and C. Diaz, The Leaking Battery. Data Privacy Management, 2015. [44] L. Olejnik, “Bug 1124127 - Round Off Navigator Battery Level on Linux,” https://bugzilla.mozilla.org/show bug.cgi?id=1124127, 2015. [45] T. Volodine, “Issue 1229143006: Enforce restricted precision of the Bat- tery Status API level attribute (Closed) ,” https://codereview.chromium. org/1229143006, 2015. [46] A. Kostiainen and M. Lamouri, “Battery Status API,” https://www.w3. org/TR/battery-status/, July 2016. [47] K. Chen, “This Is Your Brain On Uber,” http://www.npr.org/2016/05/ 17/478266839/this-is-your-brain-on-uber, 2016. [48] B. Carson, “You’re more likely to order a pricey Uber ride if your phone is about to die,” http://uk.businessinsider.com/people-with-low-phone- batteries-more-likely-to-accept-uber-surge-pricing-2016-5, 2016. [49] J. Golson, “Uber knows you’ll probably pay surge pricing if your battery is about to die,” http://www.theverge.com/2016/5/20/11721890/ uber-surge-pricing-low-battery, 2016. [50] M. Caceres, “Re: Notes of June 30 teleconference,” https://lists.w3.org/ Archives/Public/public-device-apis/2016Jul/0000.html, 2016. [51] P.-O. Dehaye, “Battery Status API,” https://github.com/pdehaye/ BigOther/blob/master/uber/uber first response.xlsx, November 2016. [52] C. Peterson, “Bug 1313580 - Remove web content access to Battery API,” https://bugzilla.mozilla.org/show bug.cgi?id=1313580, 2016. [53] Mozilla, “Firefox 52 Release Notes,” https://www.mozilla.org/en- US/firefox/52.0/releasenotes/, 2017. [54] B. Eidson, “Bug 164213 - Remove Battery Status API from the tree ,” https://bugs.webkit.org/show bug.cgi?id=164213, 2016. [55] L. Olejnik, “Issue 661792 - Battery API raises privacy issues,” https: //bugs.chromium.org/p/chromium/issues/detail?id=661792, 2016. [56] Microsoft, “Platform Status Suggestions,” https://wpdev.uservoice. com/forums/257854-microsoft-edge-developer/suggestions/6263689- battery-status-api, 2012. [57] Yandex Browser Blog, “ Beware Evil APIs ,” https://browser.yandex. com/blog/beware-evil-apis, 2016. [58] L. Olejnik, “Issue 661792 - Battery API raises privacy issues,” https: //bugs.chromium.org/p/chromium/issues/detail?id=661792#c4, 2016. [59] Mozilla, “Firefox 52 for developers (release notes) ,” https://developer. mozilla.org/en-US/Firefox/Releases/52#Others, 2017. [60] A. Konstiainen, “Allow use from within secure context and top-level browsing context only,” https://github.com/w3c/battery/issues/10, 2017. [61] Chris Peterson, “Removing the Battery Status API?” https: //groups.google.com/forum/#!msg/mozilla.dev.platform/5U8NHoUY- 1k/9ybyzQIYCAAJ, 2016.