=Paper=
{{Paper
|id=Vol-1873/IWPE17_paper_18
|storemode=property
|title=Battery Status Not Included: Assessing Privacy in Web Standards
|pdfUrl=https://ceur-ws.org/Vol-1873/IWPE17_paper_18.pdf
|volume=Vol-1873
|authors=Lukasz Olejnik,Steven Englehardt,Arvind Narayanan
|dblpUrl=https://dblp.org/rec/conf/sp/OlejnikEN17
}}
==Battery Status Not Included: Assessing Privacy in Web Standards==
https://ceur-ws.org/Vol-1873/IWPE17_paper_18.pdf
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.