Re: Tracking via Battery status makes the news

Hi,

> On 04 Aug 2015, at 02:53, Nick Doty <npdoty@w3.org> wrote:
> 
> 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,

I revised the security and privacy considerations [1] based on feedback from the authors of the paper. Feedback and suggestions from PING on how to improve that section appreciated.

> or is this API likely to be deprecated for the generic sensor API?

This API ships in Chrome stable, and an earlier version has shipped in Firefox for years, so my expectation is it will not get deprecated. The problematic implementation (per the published paper) was Firefox. Luckily, Mozilla is in process of revising its implementation [2] to match the latest spec and on the same pass they could address the fingerprinting vector. Once we settle on the guidance, we should chime in on [2].

> 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.

I'm also a bit hesitant to introduce permission dialogs for this API, due to it being bad for the UX. I worded that recommendation as a MAY in [1]. Perhaps we should rephrase it. Suggestions?

Thanks,

-Anssi

[1] https://dvcs.w3.org/hg/dap/raw-file/default/battery/Overview.html#security-and-privacy-considerations
[2] https://bugzil.la/1047119

Received on Thursday, 20 August 2015 13:16:15 UTC