Designing standards with privacy in mind should be a standard in itself. Historically this was not always the case and the idea of designing systems with privacy is relatively new – it dates from the beginning of this decade. One of the milestones is accepting this view on the IETF level, dating 2013.
This note and the referenced research work focusses on designing standards with privacy in mind. The World Wide Web Consortium (W3C) is one of the most important standardization bodies. W3C is standardizing something everyone – billions of people – use every day for entertainment or work, the web and how web browsers work. It employs a focused, lengthy, but very open and consensus-driven environment in order to make sure that community voice is always heard during the drafting of new specifications. The actual inner workings of W3C are surprisingly complex. One interesting observation is that the W3C Process Document document does not actually mention privacy reviews at all. Although in practice this kind of reviews are always the case.
However, as the web along with its complexity and web browser features constantly grow, and as browsers and the web are expected to be designed in an ever-rapid manner, considering privacy becomes a challenge. But this is what is needed in order to obtain a good specification and well-thought browser features, with good threat models, and well designed privacy strategies.
My recent work, together with the Princeton team, Arvind Narayanan and Steven Englehardt, is providing insight into the standardization process at W3C, specifically the privacy areas of standardization. We point out a number of issues and room for improvements. We also provide recommendations as well as broad evidence of a wide misuse and abuse (in tracking and fingerprinting) of a browser mechanism called Battery Status API.
Battery Status API is a browser feature that was meant to allow websites access the information concerning the battery state of a user device. This seemingly innocuous mechanism initially had no identified privacy concerns. However, following my previous research work in collaboration with Gunes Acar this view has changed (Leaking Battery and a later note).
The work I authored in 2015 identifies a number or privacy risks of the API. Specifically – the issue of potential exploitation of the API to tracking, as well as the potential possibility of recovering the raw value of the battery capacity – something that was not foreseen to be accessed by web sites. Ultimately, this work has led to a fix in Firefox browser and an update to W3C specification. But the matter was not over yet.
In 2016, Englehardt and Narayanan published a report (Online Tracking:
A 1-million-site Measurement and Analysis) that has validated my previous work – they have identified the misuse of this API in the wild. Together with the fact that battery information may bring second-order privacy risks due to price discrimination (based on an Uber study – and by the way, Uber is collecting battery), it became clear that the matter had to be addressed.
Browser vendors reacted in a number of ways. In October 2016, Mozilla decided to remove the Battery Status API from Firefox; I previously wrote about this. WebKit did the same, which means that Safari browser will not enable the API (although it has never actually did so). Yandex Browser has decided to offer the API in an opt-in manner – the user needs to explicitly enable the API. In March 2017, Firefox has shipped with the API removed, an unprecedented move in the history of the web; for the first time, an entire API has been purged citing privacy concerns.
Our most recent work (Battery Status Not Included: Assessing Privacy in Web Standards) will be presented at the IEEE Privacy Engineering Workshop (May, San Jose), where we provide a detailed study and a deep analysis.
Further evidence of Battery Status API use to tracking
First, we report that we have found a wide misuse and abuse of Battery Status API. We provide evidence that the API is used for purposes it was not designed to. We found 16 third-party scripts using the API in tracking, 11 of them is using the API for fingerprinting purposes.
Battery in context of active fingerprinting
We found fingerprinting script of Augur.io, a provider of device recognition services whose marketing material advertises “cookie-less tracking“. The script collects a large number of device properties: the device’s fonts, plugins, WebGL properties, screen information, processor information, whether or not the device is blocking ads, whether or not the device is blocking cookies, and more. From the Battery Status API, the script collects the current charge level and combines it with the other device properties. The script sends a heavily obfuscated payload back to Augur’s server.
We found Augur’s use of the Battery Status API for fingerprinting on 16 of the top 50,000 sites measured. Using previous data, we also identified that 166 sites have been including the scripts on the top 1 million sites.
Battery information for fraud detection
Another interesting example is a script provided by Riskified.com. Riskified is a provider of fraud detection tools for e-commerce. It appears to use Battery-related attributes as a part of a user reputation score (as a behaviometric feature). We highlight that Battery Status API was not designed to allow behavioral profiling with aim of fraud detection.
Summary
Additionally, I’m quickly mentioning a recent result testing the profiling based on battery status information. Although it’s use has been validated for continuous authentication systems of mobile device users – that’s an interesting hint how Battery Status information can help in user profiling and identification. Practical use of Battery Status information to fraud detection or fingerprinting is perhaps an interesting use case, although it was not among the original use cases.
But what we learned based on this story is rich for the emerging field of privacy engineering.
Lessons Learned
The history of Battery Status API became a model case in development of web standards and browser features. It is surprisingly rich experience. Based on a deep analysis, taking into account research and participation in standardization activities, we also provide recommendations.
Information exchange between vendors and researchers is essential.
Privacy risks and threats are complex and a still emerging research field, with a lot of unobvious cases, strict cooperation between standardizers, implementers and researchers is a must. We have actually validated this pattern, based on Battery Status API and how the information propagated among vendors.
The specification process should include a privacy review of implementations.
When experimental implementations are available, why not use them in privacy reviews to improve the design of the specifications? We recommend that specification authors study implementations to prepare higher quality privacy assessments. Implementation enables field testing of theoretical attacks and can be examined for potential API misuses. I personally follow this recommendation.
API use in the wild should be audited after implementation.
How is the API used in practice? In case of Battery Status API, the API turned out to be misused in a large number of cases. The benefits of doing an early audit are two-fold: misuses of the API that weren’t found during the privacy assessment may be discovered, and any uncovered vulnerability can be fixed at the specification level before web compatibility and breakage become a concern.
Specification authors should carry out privacy assessments with multiple threat models
Privacy engineering is difficult. We recommend that if any privacy vulnerability is identified, possible exploitation should be modeled and analyzed in detail. Privacy assessment methodologies must evolve to keep abreast of the growing technical complexity of web APIs.
Avoiding over-specification supports innovative privacy solutions
W3C specifications are expected to be well defined, but do allow implementers significant leeway. We recommend that standards exploit this flexibility to set a privacy floor yet leave room for innovative privacy solutions by implementers. Over-specification may have the unintended effect of rendering some privacy solutions non-interoperable with the standard or with other web features.
Specifications should provide guidance for web developers, not just browser vendors
Web developers are ultimately the end consumers of new features and are responsible for complying with local data protection regulations. To assist these developers, specifications should highlight if a particular feature provides sensitive data. That’s a matter of documentation that can also help browser vendors.
Specifications should not only identify points of privacy concern for browser vendors and other implementers, but should also provide useful guidance for web application developers when possible.
Recommendation for standardization bodies (here, namely: W3C)
Incentivize research in web privacy engineering, including standards. For example hold dedicated venues, such as regular research conferences or workshops, fostering active research in the field.
Include the need for privacy reviews in the design process. Specifically, update the W3C Process document, even if there are specific notes or other documents.
Recommendation for browser vendors (and standardizers)
Help in audits and transparency. Deploy built-in browser probes or a dedicated web crawling infrastructure run by browser vendors or privacy advocacy groups. One can imagine a simple API-based probes where it’s easy to detect the frequency and context of use of particular browser APIs.
Conclusion
Privacy research can have a positive influence on standards and implementations. I feel that our case study and recommendations will prove useful to standards bodies, browser vendors, and web developers. We also hope that privacy impact assessment and other sound privacy engineering practices will make inroads into nascent domains such as the Internet of Things.
I had the great opportunity to feel and experience the development of privacy standardization as a privacy researcher, as well as a W3C Invited Expert. I am also looking forward to participate in future privacy engineering research and development.
This post originally appeared on Security, Privacy & Tech Inquiries, the blog of Lukasz Olejnik. For the full paper to appear at Privacy Engineering Workshop, see here: Battery Status Not Included: Assessing Privacy in Web Standards.