Re: Tracking via Battery status makes the news

I appreciate this being re-raised as I had only skimmed it before. I was, similar to the authors of the paper, surprised to see the level of detail exposed in the API.

Are there issues in the DAP tracker regarding this issue or potential updates to the spec? Should the Privacy Interest Group conduct a deeper review, or is this API likely to be deprecated for the generic sensor API?

My concerns would be (from a very brief review):
* a privacy and security considerations that says there aren't any security considerations is a red flag; in this case we should at least note the very substantial concern
* triggering of events on every battery change makes it easier to identify the same user across origins, across windows where one is private browsing or even across browsers altogether
* does the exact percentage need to be revealed? couldn't almost all use cases be accomplished through two booleans:  `charging` and `lowBattery`?

Regarding the concrete suggestions, I think the tendency is to limit the number of permission dialogs, and I'm not sure we would want to encourage that here. If we can reduce granularity in a way that decreases the risk and maintains the functionality, then the permission dialog wouldn't be as much of a problem. We could also give advice on lower granularity responses for browsers, especially those with users concerned about privacy implications.

Hope this helps,
Nick

> On Aug 3, 2015, at 1:07 PM, Frederick Hirsch <w3c@fjhirsch.com> wrote:
> 
> [sharing news item with DAP, noting earlier related thread. Deliberately cross posting]
> 
> Tracking via Battery status makes the news, see below
> 
> This relates to our earlier email discussion related to the corresponding research article that had some concrete suggestions:
> 
> https://lists.w3.org/Archives/Public/public-device-apis/2015Jul/0010.html <https://lists.w3.org/Archives/Public/public-device-apis/2015Jul/0010.html>
> 
> Perhaps we need to update the Battery Status API draft sooner rather than later...
> 
> regards, Frederick
> 
> Frederick Hirsch
> Chair, W3C Device APIs WG (DAP)
> 
> www.fjhirsch.com <http://www.fjhirsch.com/>
> @fjhirsch
> 
> 
>> Begin forwarded message:
>> 
>> From: Joseph Lorenzo Hall <joe@cdt.org <mailto:joe@cdt.org>>
>> Subject: Fwd: [discuss] Batteries & tracking
>> Date: August 3, 2015 at 12:41:13 PM EDT
>> To: "public-privacy (W3C mailing list)" <public-privacy@w3.org <mailto:public-privacy@w3.org>>
>> Resent-From: public-privacy@w3.org <mailto:public-privacy@w3.org>
>> 
>> 
>> http://www.theguardian.com/technology/2015/aug/03/privacy-smartphones-battery-life <http://www.theguardian.com/technology/2015/aug/03/privacy-smartphones-battery-life>
>> 
>> A little-known feature of the HTML5 specification means that websites can find out how much battery power a visitor has left on their laptop or smartphone – and now, security researchers have warned that that information can be used to track browsers online.
>> 
>> 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.
>> 
>> W3C’s specification explicitly frees sites from needing to ask user permission to discover they remaining battery life, arguing that <http://www.w3.org/TR/2012/CR-battery-status-20120508/> “the information disclosed has minimal impact on privacy or fingerprinting, and therefore is exposed without permission grants”. But in a new paper from four French and Belgian security researchers <http://eprint.iacr.org/2015/616.pdf>, that assertion is questioned.
>> 
>> 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.
>> 
>> For instance, if a user visits a website in Chrome’s private browsing mode using a VPN, the website should not be able to link them to a subsequent visit with private browsing and the VPN off. But the researchers warn that that may no longer work: “Users who try to revisit a website with a new identity may use browsers’ private mode or clear cookies and other client side identifiers. When consecutive visits are made within a short interval, the website can link users’ new and old identities by exploiting battery level and charge/discharge times. The website can then reinstantiate users’ cookies and other client side identifiers, a method known as respawning.”
>> 
>> Worse still, on some platforms, the researchers found that it is possible to determine the maximum battery capacity of the device with enough queries, creating a semi-permanent metric to compare devices.