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] 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. INTRODUCTION 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 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 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