Firefox Removing Battery Status API

Firefox is removing the battery status API, citing privacy concerns. Here’s the paper that described those concerns:

Abstract. We highlight privacy risks associated with the HTML5 Battery Status API. We put special focus on its implementation in the Firefox browser. Our study shows that websites can discover the capacity of users’ batteries by exploiting the high precision readouts provided by Firefox on Linux. The capacity of the battery, as well as its level, expose a fingerprintable surface that can be used to track web users in short time intervals. Our analysis shows that the risk is much higher for old or used batteries with reduced capacities, as the battery capacity may potentially serve as a tracking identifier. The fingerprintable surface of the API could be drastically reduced without any loss in the API’s functionality by reducing the precision of the readings. We propose minor modifications to Battery Status API and its implementation in the Firefox browser to address the privacy issues presented in the study. Our bug report for Firefox was accepted and a fix is deployed.

W3C is updating the spec. Here’s a battery tracker found in the wild.

Tags: , , , , , ,

Posted on November 7, 2016 at 12:59 PM • 21 Comments

Comments

aconrad • November 7, 2016 3:08 PM

Privacy-invading features manage to get into browsers all the time, but this one surprises me. Someone thought it was a good idea for a website to be able to query my battery level? And this isn’t some forgotten decade-old thing, it was added in the last year!

The justification? “Without knowing the battery status of a device, a web developer must design the web application with an assumption of sufficient battery level for the task at hand. This means the battery of a device may exhaust faster than desired because web developers are unable to make decisions based on the battery status. Given knowledge of the battery status, web developers are able to craft web content and applications which are power-efficient” [only when they detect the battery is dying, presumably–because if they were efficient before that, they wouldn’t need to know the battery state, would they?].

So, they decided people should be able to query your battery level and charging/discharging times/status to make, basically, a binary decision. I’d be curious to know whether anyone’s using this, and if so, is the high-battery-drain version something I’d actually want? Or should we just program our browsers to report a battery in its death throes, to get a more pleasant experience. (We used to just disable Javascript when we wanted web sites to stop wasting CPU, but “modern” sites seem intent on forcing everyone to enable scripts.)

By the way, the spec papers over the idea of privacy: “The user agent SHOULD not expose high precision readouts of battery status information as that can introduce a new fingerprinting vector.” But really, you can tell they don’t care because they defined chargingTime and dischargingTime in seconds. And because a lot of “MUST” requirements conflict with “The user agent MAY obfuscate the exposed value”.

Karen Silverstone, Nightmute • November 7, 2016 4:06 PM

Ghacks has a ongoing project admirably run by ‘Pants’ which is a list of changes to about:config setting (including a number of hidden ones) that optimise privacy and security making for a ‘quieter’ firefox that doesn’t phone home in a million different ways.
Okay, we KNOW browsers are broken and we know privacy is verging on impossible, but in case of risk mitigation
I mention this because the battery canvas fingerprint mentioned above is one of the many that can be deactivated in about:config

Pants appears to be a reader here incidentally so a shout out should
attract him/her if feedback needed :-0

Anon • November 7, 2016 5:35 PM

This is my single biggest complaint with web browsers – they are not web browsers at all, but are in fact full programming environments in a box.

They are a dangerous version of virtual machine, in that they are not virtualized, and without any protections.

Why does a web site need access to battery status AT ALL? Just what is the justification of the existence of this API?

Instead of changing the API, they should remove it entirely.

aconrad • November 7, 2016 7:48 PM

Karen, thanks for mentioning the ghacks project. I wasn’t aware of it but have a list of several hundred similar settings I’ve been accumulating for years (not all for security; some disable annoyances like animations, and one is just there to revert some of the pointless ‘transient’ changes that make ‘git diff’ difficult). Some quick notes:

  • Instead of user.js, you can put a ‘preferences’ directory in your profile and firefox will import preferences/*.js at startup. Useful if you want to have different groups of settings applied to different profiles (use symlinks to a common location managed by git).
  • For a secure profile for banking etc., disable unencrypted traffic:
    user_pref(“network.proxy.http”, “127.0.0.1”);
    user_pref(“network.proxy.http_port”, 9);
    user_pref(“network.proxy.ftp”, “127.0.0.1”);
    user_pref(“network.proxy.ftp_port”, 9);
    user_pref(“network.proxy.type”, 1);
    user_pref(“network.proxy.no_proxies_on”, “EVIntl-aia.verisign.com example.com”); # add other sites needed for ocsp
    user_pref(“security.OCSP.require”, true);
  • There’s no easy way to disable certificate authorities in the UI (that I know of), but there’s an easy hack on Linux: create a file named libnssckbi.so (it might need to be a valid ELF library but doesn’t need any symbols) and stick it at the start of your $LD_LIBRARY_PATH. Be sure to compare certificate fingerprints with a CA-enabled browser before accepting them (ideally using a different network path–try Tor, and note that most sites blocking Tor will give the 403 after certificate negotiation).

Crotch Hound • November 8, 2016 12:13 AM

Although I respect the decision that Mozilla has made to remove this useless API – these developers sure have a lot of work to do if this decision was made to prevent browser fingerprinting.

There is also audio fingerprinting, which is not yet widely implemented across websites, however serves as a permanent unique identifier (Similar to HTML canvas fingerprinting).

https://audiofingerprint.openwpm.com/

There are an astonishing amount of ways that JavaScript is able to retrieve information about a persons browsing profile and habits. DOM user timing, plugin detection, user agent, keystroke timing, browser fonts, OS time zone matching, accepted languages (which can be used to find an approximate location of someone behind a vpn….you get the idea.

Herman • November 8, 2016 2:05 AM

It will make no difference. A browser can be uniquely identified anyway, due to the OS, fonts, installed plugins and their version numbers.

keiner • November 8, 2016 2:26 AM

Maybe they should remove some more trash, while they are on it. Opened a current firefox on a linux machine (with one EMPTY tab) and did a wireshark. Found more than 600 packages going in/out. Really amazing….

PantsHunt42 • November 8, 2016 3:11 AM

@keiner – you can disable ALL of that. Most of what you are seeing is likely updates for safebrowsing and mozilla telemetry/health-reports/experiments and update checks. Nothing that any other major browser doesn’t do.

What they should be ditching is this sort of rubbish: http://www.theregister.co.uk/2016/05/24/pointless_features_add_to_browser_bloat_and_insecurity/
original: https://arxiv.org/abs/1605.06467 with the PDF paper link top right

@Herman – the only way to defeat fingerprinting is by OpSec (also dependent on who you are trying to defeat), there are too many holes. That said, you can block font enumeration, plugin & mime type enumeration and more. The trick is to know when to spoof and when to randomize and when to leave alone. TBB covers this well if you look at their draft design spec: https://www.torproject.org/projects/torbrowser/design/index.html.en#fingerprinting-linkability : scroll down a little to “General Fingerprinting Defenses”

To quote Arthur Edelstein: “The approach in Tor Browser is not to blend in with all web users (which is impossible), but rather to make all Tor Browser users indistinguishable from one another.” Outside of TBB, what is needed is for a substantial number of end users to buy into the same exact settings (and yes, there needs to be more work done on OS, locale, date-time, date formats, keyboard fingerprinting, etc).

FYI: for those who were not aware: The Tor Uplift Project: https://wiki.mozilla.org/Security/Tor_Uplift/Tracking

PantsHunt42 • November 8, 2016 3:22 AM

^^ I meant scroll down to “Strategies for Defense: Randomization versus Uniformity”

PantsHunt42 • November 8, 2016 5:40 AM

@65535 – I do not believe in any UA spoofing. There are just so many methods to “determine” your browser that it’s pointless (not all methods have to provide the actual name). All you do is raise your entropy. Take for example resource URI leaks, or that currently all extensions and about:config entries do not cover leaking your UA via an iframe (although I believe RAS does now via script injection) – see https://github.com/pyllyukko/user.js/issues/193 (so there’s your answer I assume, RAS – make sure to cover headers and JS methods for obtaining the UA string, but don;t be fooled that there aren’t other ways to work out your browser)

PS: you missed the latest article: http://www.ghacks.net/2016/07/03/comprehensive-firefox-user-js/ . The original article is always updated, so stick to that for comments and updates. One day I will github it.

65535 • November 8, 2016 6:48 AM

@PantsHunt

“raise your entropy.”

I guess you are saying raise the ability to fingerprint your browser?

I that is correct it means that using a browser spoofer adds one more increment of attack surface area and one more ID data point to those who do browser finger printing. Well, so much for browser spoofers – another useless add on.

I have to your link book marked. Thanks.

ljones • November 8, 2016 8:00 AM

Intresting idea, but far too little too late. The amount of battery charge isn’t the only thing that can be used as others have said.

I did take a look at that ghacks website btw. I read through it and I may give the user.js trick a try, although …. why is that page on that website running 5 trackers (two of which are from google). Slightly odd that a webpage about browser security would also want to track me ’round the internet’; evidently someone didn’t get the memo somewhere. But I digress.

Why on earth do web browsers give out so much information at all these days? Maybe there’s a project in there somewhere – take out all the stuff that isn’t needed in HTML5, Javascript and soforth and have that in a browser instead. Or maybe at least have some sort of option to enable only the most basic features needed to browse/login/post and no more.

It is intresting just how over-bloated and slow it has all become over about the course of a decade. I can remember just a decade ago having an old PC here. It wasn’t much – A 233Mhz pentium with 32MB of RAM. It ran a gnu/linux distro “puppy linux” just fine. And while it was no speed daemon I could use the internet on it reasonably well.

Nowadays though you need 2GB of ram and a 3Ghz quad core whatchamacallit just to get started. Anything less and everything becomes painfully slow (try viewing the BBC’s (UK) main news website on an older PC and watch it crawl x.x).

ljones

keiner • November 8, 2016 8:05 AM

@Pants: Highly appreciate your effort to make FF more safe/secure, but isn’t it a SHAME that I have to copy some cryptic, 1000-liner into the config of my browser to turn of sick stuff the developers simply didn’t care for?

Just asking…

keiner • November 8, 2016 8:16 AM

@ljones

100% agree! I’m trying PaleMoon (derivative of FF) for some computers. Should have smaller footprint, will see how it works…

PantsHunt42 • November 8, 2016 8:40 AM

@65535 yes, “raise your entropy”, I should have clarified that as being when you spoof and it is detected.

Besides that hole in iframes, rather than navigator.userAgent or User-Agent HTTP header, you can identify a browser by:
– property order of special browser objects, such as navigator and screen objects, which depends on a browser, its version and operating system
– presence of some unique methods and properties of special browser objects, such as navigator.mozSms( Firefox ), navigator.webkitStartActivity( Chrome ), navigator.appMinorVersion( IE )
– modification of special objects with Javascript (eg checking if a script can delete an object property, replace one property with another, or delete the whole object)
– new browser features introduced in each version.

Anyone who thinks spoofing their UA is doing ANY good is deluded.

Joe • November 8, 2016 10:23 PM

Paper shows the majority of fingerprinting is done via javascript. Canvas, WebRTC, fonts, battery level, and even audio fingerprinting all requires javascript to be enabled for it to work, apparently.

The section about people being redirecting to a different website than they’re trying to visit is interesting. Apparently this is done in order to plant 1st-party tracking cookies on people in case they have 3rd-party cookies disabled in their browser settings.

On a side note, most drive by malware infections also require javascript or flash to be enabled in order for them to drop their payloads on a victim’s system.

It’s a pain but I use NoScript to disable all javascript and whitelist scripts on a one-by-one basis as I browse the net.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.