Introduction

Privacy risks and threats arise and surface even in seemingly innocuous mechanisms. We have seen it before, and we will see it again.

Recently, I participated in a study assessing the risk of 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.

Edit 28.10.16: Mozilla's unprecedented decision to remove (another link) Firefox support from web-facing battery level readout due to privacy concerns.

Privacy analysis of Battery API

Battery readouts provide the following information:

  • the current level of battery (format: 0.00-1.0, for empty and full, respectively)
  • time to a full discharge of battery (in seconds)
  • time to a full charge of battery, if connected to a charger (in seconds)

Those values are updated whenever a new value is supplied by the operating system

What might be the issues here?

Frequency of changes

Frequency of changes in the reported readouts from Battery Status API potentially allowed the monitoring of users' computer use habits; for example, potentially enabled 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 mechanism 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 to see (and target?) particular users.

Battery readouts as identifiers

The information provided by the Battery Status API is not always changing fast. In other words, they are static for a period of time; it may give rise to a short-lived identifier. At the same time, users sometimes clear standard web identifiers (such as cookies). But a web script could analyze identifiers provided by Battery Status API, which could then possibly even lead to recreation of other identifiers. A simple sketch follows.

An example web script continuously monitors the status of identifiers and the information obtained from Battery API. At some point, the user clears (e.g.) all the identifying cookies. The monitoring web script suddenly sees a new user - with no cookie - so it sets new ones. But battery level analysis could provide hints that this new user is - in fact - not a new user, but the previously known one. The script's operator could then conclude and reason that those this is a single user, and resume with 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 system. We made a test script which was exploiting the too verbose readout (i.e. 0.932874 instead of a sufficient 0.93) of battery level and combined this information with the knowledge of how the battery level is 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 the paper report.

Results

The study achieved an impact.

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 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 most unlikely mechanisms bring unexpected consequences from privacy point of views. That's why it is necessary to analyze new features, standards, designs, architectures - and products with a privacy angle. This careful process will yield results, decrease the number of issues, abuses and unwelcome surprizes.