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

Re: Tracking via Battery status makes the news

From: Joseph Lorenzo Hall <joe@cdt.org>
Date: Thu, 27 Aug 2015 11:03:08 -0400
Message-ID: <CABtrr-U6FSrM3L6nWvAz3ahjtgY7pq2gbQvoMz_En6WDkD9+ug@mail.gmail.com>
To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
Cc: Nick Doty <npdoty@w3.org>, Frederick Hirsch <w3c@fjhirsch.com>, W3C Device APIs WG <public-device-apis@w3.org>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>
On Thu, Aug 20, 2015 at 9:15 AM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

> 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.
>
>
This is a great revision and I'm hopeful that it will help to avoid these
kinds of problems in the future! Thanks... PING, we may want to include
something about precision in our privacy questionnaire. Not sure where.


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


-- 
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
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
Received on Thursday, 27 August 2015 15:03:59 UTC

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