How Your Phone’s Battery Life Can Be Used to Invade Your Privacy
The battery status API is currently supported in the Firefox, Opera and Chrome browsers, and was introduced by the World Wide Web Consortium (W3C, the organisation that oversees the development of the web’s standards) in 2012, with the aim of helping websites conserve users’ energy. Ideally, a website or web-app can notice when the visitor has little battery power left, and switch to a low-power mode by disabling extraneous features to eke out the most usage.
[…]
The researchers point out that the information a website receives is surprisingly specific, containing the estimated time in seconds that the battery will take to fully discharge, as well the remaining battery capacity expressed as a percentage. Those two numbers, taken together, can be in any one of around 14 million combinations, meaning that they operate as a potential ID number. What’s more, those values only update around every 30 seconds, however, meaning that for half a minute, the battery status API can be used to identify users across websites.
Update (2016-11-05): Catalin Cimpanu (via Hacker News):
In an unexpected move, Mozilla has announced last week it was removing support for the Battery Status API, a feature that allows websites to detect the status of the user’s battery level, and use this information to save critical website data to disk before the device shuts down.
Unfortunately, web developers haven’t used the API as Mozilla had hoped. In fact, the most ardent users of the API are advertisers, who used it to track users across websites based on their battery levels and unique device identifiers.
Update (2016-11-07): Lukasz Olejnik:
It’s also interesting to note that Apple is considering to remove support for Battery Status API from WebKit’s (the engine powering Safari browser) source code. Although so far Apple has not enabled Battery Status API, it is implemented in Safari’s engine. At this point, I don’t believe Apple will ever ship this feature.
Update (2016-11-08): Bruce Schneier:
W3C is updating the spec. Here's a battery tracker found in the wild.
2 Comments RSS · Twitter
Good grief. That is an utterly appalling technology design, and a completely unjustifiable one too:
1. Implicitly sending detailed client information to the server is a serious invasion of user privacy and an open invite to security holes. HOW THE USER'S MACHINE CHOOSES TO OPERATE IS NONE OF THE SERVER'S BUSINESS. The server's role is to deliver content requested by the client in a mutually agreed format, not to dictate to the client how to do its job†.
2. The HTTP transport protocol already defines a content negotiation mechanism that allows the client to express its own content preferences and requirements to the server. And does it WITHOUT GIVING AWAY ANY PERSONAL INFORMATION whatsoever.
.
Thus the entire battery status API should never have been created in the first place: not only does it add technical complexity and a security hole, but it completely (and very badly) duplicates (well-designed) functionality that already exists in HTTP.
At most, the only thing the W3C needed to do was define a new 'Accept*' header allowing the client to indicate its preference for 'low-power' content.††
But, of course, nobody ever got rich, powerful, and famous by saying "Let's NOT do something!" And so the great Web Industry circle-jerk continues to turn, while its wheels continue to fly off in every direction.
I really hope the revolution comes soon, as the whole bloody lot of them are madly overdue for being first against the wall...
--
† A massive violation of Coupling and Cohesion 101 that should be automatic grounds for tarring, feathering, and running the incompetents out of the profession.
†† Content negotiation would make it vastly more useful to clients too, as (e.g.) it'd allow low-power devices always to indicate a preference for 'low-power' content in order to maximize their total battery lifetime (instead of being forced to wait until their batteries are at their last gasp, then forced to switch modes whether they want to or not, with all the user disruption and confusion that'll doubtless result).
"Good grief. That is an utterly appalling technology design, and a completely unjustifiable one too:"
Fully agree that it's appalling, but for the mobile browsing this exploit involves, it's obviously one of the least of your tracking worries.
Given that seemingly a majority of wireless providers, both in the US and overseas, are now adding supercookies, you should assume that all of your non-https traffic is being commercially tracked and sold. And supercookes are just one of the many tracking vectors.
Pretty much all non-https traffic is vulnerable to commercial tracking, via one vector or another. And that applies to both mobile and non-mobile traffic. Even https traffic has lesser, but still quite real vulnerabilities. (And, of course, once we start getting to the separate topic of heavily-resourced governmental tracking, all bets are completely off...)
In short: All your meta-data are belong to us.
