Tracking via Battery status makes the news

[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>
> 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>
> Resent-From: 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.
> 
> 
> -- 
> Joseph Lorenzo Hall
> Chief Technologist
> Center for Democracy & Technology
> 1634 I ST NW STE 1100
> Washington DC 20006-4011 
> (p) 202-407-8825
> (f) 202-637-0968
> joe@cdt.org <mailto:joe@cdt.org>
> PGP: https://josephhall.org/gpg-key <https://josephhall.org/gpg-key>
> fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
> 
> 

Received on Monday, 3 August 2015 20:08:08 UTC