Privacy risks and threats arise even in seemingly innocuous mechanisms. It is a fairly regular issue.
Over a year ago, I was researching the risk of the W3C Battery Status API. The mechanism allows a web site to read the battery level of a device (smartphone, laptop, etc.). One of the positive use cases may be, for example, stopping the execution of intensive operations if the battery is running low.
Our privacy analysis of Battery Status API revealed interesting results.
Privacy analysis of Battery API
The battery status provides the following information:
- the current level of battery (format: 0.0–1.0, for empty and full battery, respectively)
- time to a full discharge of battery (in seconds)
- time to a full charge of battery, if connected to a charger (in seconds)
These items are updated whenever a new value is supplied by the operating system
It turns out that privacy risks may surface even in this kind of – seemingly innocuous – data and access mechanisms.
Frequency of changes
The frequency of changes in the reported readouts from Battery Status API potentially allow the monitoring of users’ computer use habits; for example, potentially enabling analyzing of how frequently the user’s device is under heavy use. This could lead to behavioral analysis.
Additionally, identical installations of computer deployments in standard environments (e.g. at schools, work offices, etc.) are often are behind a NAT. In simple terms, NAT allows a number of users to browse the Internet with an – externally seen – single IP address. The ability of observing any differences between otherwise identical computer installations – potentially allows particular users to be identified (and targeted?).
Battery readouts as identifiers
The information provided by the Battery Status API is not always subject to rapid changes. In other words, this information may be static for a period of time; this in turn may give rise to a short-lived identifier. The situation gets especially interesting when we consider a scenario of users sometimes clearing standard web identifiers (such as cookies). In such a case, a web script could potentially analyse identifiers provided by Battery Status API, and this information then could possibly even lead to re-creation of other identifiers. A simple sketch follows.
For example, a web script could continuously monitor the status of identifiers and the information obtained from the Battery API. At some point, the user clears all the identifying cookies. The monitoring web script suddenly sees an apparently new user – with no cookie – so the web script sets a new one. But battery level analysis could provide hints that this new user is – in fact – not a new user, but a previously known one. The script’s operator could then conclude and reason that this is a single user, and resume tracking. This is an example scenario of identifier recreation, also known as respawning.
Recovering battery capacity
This was surprising! It turned out that in some circumstances it was possible to approximate (recover) the actual battery capacity in raw format; in particular on Firefox under Linux. Specifically, the provided readout was too precise. For example, a web site could read the value of 0.932874 (93% battery level). We tested an approach exploiting that too verbose readout of battery level and combined this information with the knowledge of how the battery level was computed by the operating system, before it is provided to the Web browser. It turned out that it was possible to even recover the battery capacity and use it as an identifier. For more information, please refer to my paper.
Results
The results of this study has had significant impact:
- the W3C standard is updated to reflect the privacy analysis
- the Firefox browser shipped a fix. (battery level readout rounded – i.e. 0.932874 instead of a sufficient 0.93)
- the work received some recognition
Trackers use of battery information
Expected or not, battery readout is actually being used by tracking scripts, as reported in a recent study. Some tracking/analysis scripts (example here) are accessing and recovering this information.
Additionally, some companies may even be analyzing the possibility of monetizing the access to battery levels. When battery is running low, people might be prone to some – otherwise different – decisions. In such circumstances, users will agree to pay more for a service. As a response, some browser vendors are considering to restrict (or remove) access to battery readout mechanisms.
Summary
Even the most unlikely mechanisms might bring unexpected consequences from a privacy point of views. These kind of analyses may be resource-consuming but they yield results, decrease the number of issues, abuses and unwelcome surprises.
This post originally appeared on Security, Privacy & Tech Inquiries, the blog of Lukasz Olejnik.