The W3C’s battery status API allows websites to see how much battery juice your device has left in its tank.
That’s handy if they want to give their juiceless users a break and back off their excessive fan-howl-inducing Flash animations but it also turns out to be very useful for tracking users too, particularly ones that really don’t want to be followed.
As I wrote last year, the life left in your battery aids tracking because it can be used, for brief windows of time, as a unique ID:
…there are 14,172,310 different values for a battery that’s discharging and double that for a battery that’s charging.
On most computers those unique IDs are short-lived, perhaps 30 seconds, but that’s still long enough to pull off some clever tricks like respawning deleted cookies, defeating incognito mode or teasing apart users with otherwise similar browser fingerprints.
Your browser will happily volunteer this ridiculously precise “super cookie” to any website that asks for it and, unlike a normal cookie, you can’t delete it.
At the time I suggested that battery status tracking would probably be combined with other techniques to improve the accuracy of browser fingerprinting – a cookie-less tracking technique that relies on the uniqueness of your browser and which is very difficult to disrupt.
Not long after I made that prediction, a big study by researchers at Princeton showed that this was exactly how the Battery Status API was being exploited in the wild.
The study looked at the real world tracking techniques used by the top 1 million websites and revealed two tracking scripts that used the Battery Status API:
One script … retrieves the current charge level of the host device and combines it with several other identifying features. These features include the canvas fingerprint and the user’s local IP address …
The second script … queries all properties of the BatteryManager interface, retrieving the current charging status, the charge level, and the time remaining to discharge or recharge. As with the previous script, these features are combined with other identifying features used to fingerprint a device.
Concerns were also raised about the potential for other forms of abuse after Keith Chen, head of economic research at Uber, revealed in an interview with NPR (National Public Radio) that users are more likely to pay Uber’s much higher “surge” rates if they are panicking because their phone is about to die.
There is no suggestion that Uber increases its prices when your battery starts to falter (Chen told NPR directly “the company doesn’t use that information to set prices”) but the interview helped fuel concerns about an API that seems to have at least a few bad use cases and little if any good ones.
As one user asked on Mozilla’s the mozilla.dev.platform Google Group, “Can anyone point to a real website using the Battery API for a legitimate purpose?”
The answer for Mozilla seems to have been “no”, or at least “not enough”, and as of version 52, its Firefox browser will be saying good riddance to the Battery Status API.
7 comments on “Firefox kills the Battery Status ‘super cookie’”
Thank you to Firefox, for killing it off. Are other browsers still providing battery status information, to web sites?
Good Step. Firefox just needs to implement FIDO and U2F support. Still can’t use my yubikey with firefox…
They do support YubiKeys in Firefox, been using them for at least 3 years now.
Good on you Firefox team, it only took you more than a year.
Other web browsers still appear to be allowing this unwanted and dangerous feature. Good that Firefox has stopped it passing this on but other browsers need to do likewise as there is no legitimate need for it.
Was the Battery Status cookie ever meaningful on a desktop?
I don’t think it was meaningful for good or bad as it never changed, so everyone would look the same.