To appear at the 2017 International Workshop on Privacy Engineering. Battery Status Not Included: Assessing Privacy in Web Standards Lukasz Olejnik Steven Englehardt Arvind Narayanan University College London Princeton University Princeton University [email protected] [email protected] [email protected] https://lukaszolejnik.com http://senglehardt.com http://randomwalker.info Abstract—The standardization process is core to the develop- formally defined recommendations for privacy assessments ment of the open web. Until 2013, the process rarely included pri- during the development of internet protocols [1]. The W3C vacy review and had no formal privacy requirements. But today has also invested considerable resources into the creation of the importance of privacy engineering has become apparent to standards bodies such as the W3C as well as to browser vendors. specialized methodologies for such privacy assessments [2], Standards groups now have guidelines for privacy assessments, [3]. This includes taking public stances on privacy expectations and are including privacy reviews in many new specifications. [4] and defining new groups and processes to evaluate privacy However, the standards community does not yet have much [5], [6], [7]. Even the frameworks used during specification, practical experience in assessing privacy. development, and publishing have been updated to encourage In this paper we systematically analyze the W3C Battery Status API to help inform future privacy assessments. We begin all specification authors to include privacy and security review by reviewing its evolution — the initial specification, which only sections [8], [9]. cursorily addressed privacy, the discovery of surprising privacy These recent advances in privacy review are timely, as new vulnerabilities as well as actual misuse in the wild, followed and proposed web features will provide websites with much by the removal of the API from major browser engines, an unprecedented move. Next, we analyze web measurement data deeper access to the user’s device and environment, especially from late 2016 and confirm that the majority of scripts used the on smartphones and Internet-of-Things (IoT) devices. Ex- API for fingerprinting. Finally, we draw lessons from this affair amples include Bluetooth connectivity [10], low-level device and make recommendations for improving privacy engineering sensors such as ambient light, acceleration, and vibration [11], of web standards. [12], and even the user’s interpupillary distance, in the context of Virtual Reality [13]. I. INTRODUCTION But why should standards consider privacy at all, rather The Battery Status API offers an interesting and unusual than leave it to browser vendors? Perhaps the market will case study of privacy assessment in the web standardization then allow each user to choose a browser that provides his process. The specification started with a typical progression: or her preferred trade-off between privacy and functionality. it went through a few iterations as a draft, was quickly imple- This argument is beguiling but simplistic — standards must fix mented by multiple browser vendors, and then progressed to many design choices to ensure interoperability, and some of a candidate recommendation — one which characterized the these will inevitably impact privacy [1]. Indeed, there are many privacy impact as “minimal”. Several years later, after it was examples of standards that impede efforts by browser vendors implemented in all major browser engines and was nearing to improve privacy without causing breakage [14]. Further, finalization, researchers discovered several privacy vulnerabil- standards allow setting a privacy floor across implementations. ities as well as misuse in the wild. In an unprecedented move, This helps avoid a race to the bottom, considering that privacy two of the three major browser engines removed support for might be a “market for lemons” [15] and is susceptible to the API and another browser moved to an opt-in model. In this numerous behavioral biases [16]. paper, authored by several of the researchers who discovered In this paper we study the privacy engineering aspects [17] the privacy problems, we reflect on these events, present new of the Battery Status API, with a focus on the standardization empirical evidence of misuse, and extract recommendations and implementation process. Specifically, for privacy reviews in future standards. Before 2013, there were no formal review processes at 1) We conduct a systematic case study of the Battery Status the major standards bodies to address privacy during the API (Section III). design and standardization of web features. This is reflected 2) We provide new measurements of Battery Status API in the lack of privacy or security considerations in many past use on the web (Section IV). specifications. However, the standards community has recently 3) We extract useful privacy engineering practices and made numerous substantial changes to address privacy during provide recommendations to improve the design process the early stages of feature development. In 2013 the IETF (Section V). We hope our work will be useful to standardization bodies, posed design impacts web tracking. Past studies have shown browser vendors, privacy engineers, researchers, and web de- that trackers frequently use many browser technologies to track velopers. We seek to enrich Privacy Impact Assessment (PIA) users: by using stateful mechanisms like cookies, localStorage, 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 RELATED WORK 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