W3C home > Mailing lists > Public > public-device-apis@w3.org > August 2015

Re: Tracking via Battery status makes the news

From: Mats Wichmann <mats@osg.samsung.com>
Date: Mon, 17 Aug 2015 20:32:13 -0600
Message-ID: <55D2992D.7040403@osg.samsung.com>
To: public-device-apis@w3.org
Hash: SHA1

On 08/03/15 17:53, Nick Doty 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, 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`?

It's important to remember that local "web apps" are a consumer of all
of these APIs as well.  Perhaps some level of differentiation needs to
start appearing.  There's certainly a use case that can be made for a
locally installed web app requesting finer grained information,
although one could argue about whether it's a particularly valid use
case. In the case of Tizen, which is my only real familiarity atm, a
locally installed app has to declare a particular privilege if it uses
various system information APIs (of which battery is one, a non-W3C
API fwiw), which means there's a gate at install time.  If the app is
going to access web pages external to the device, a second privilege
declaration is needed.  I'm not sure the Tizen developers have thought
about this issue either, with those two a malicious app could call
home and reveal this level of information, and we all know how much
the average user pays attention to the "this app needs access to A, B
and C" before they click install (sigh). But that part of it is a
different issue.

Version: GnuPG v1

Received on Tuesday, 18 August 2015 02:32:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:06 UTC