W3C home > Mailing lists > Public > public-privacy@w3.org > January to March 2013

Re: PING - please volunteer - Ambient Light Events

From: Nicholas Doty <npdoty@w3.org>
Date: Fri, 11 Jan 2013 20:12:40 -0800
Cc: "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Message-Id: <05EE876D-FDBC-4EB6-B5AE-9A581F295AD1@w3.org>
To: Christine Runnegar <runnegar@isoc.org>
On Dec 17, 2012, at 11:46 PM, Christine Runnegar <runnegar@isoc.org> wrote:
> The draft is available at  http://www.w3.org/TR/2012/WD-ambient-light-20121213/
> Deadline for completion of the review is 17 January 2012.

I've enjoyed the conversation on this thread already; I thought I could both share some potential privacy concerns and touch on the atomicity question.

Some of the comments on the Ambient Light thread and the Proximity thread has been on the question of whether ambient light information or proximity information is itself personal, the kind of thing that a user might not want to share for privacy reasons. I agree with what appears to be a consensus here: sensations of levels of ambient light are themselves not a substantial privacy concern. (Dave Singer does point out one potential use case -- you write a message claiming that you're at home in the dark and your phone tells your recipient that you're lying. I'm not convinced this is a major issue.)

On the other hand, a site might be able to use ambient light (or proximity) sensation in combination with other data to allow for unexpected identification of a user. I see two (or perhaps three, though I admit the last may be far-fetched) ways that this could be a concern:

1) Simultaneous initiation of ambient light change events with the same values allows JS code running in two different contexts (say, in iframes embedded into two different windows) to determine that multiple contexts are the same user on the same device. Ambient Light provides similar info to that of a proposed Idle API; see Mozilla discussion here: https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.webapi/7mEN0gSryCk

Potential mitigations: 
* Guidance that implementers should initiative the events only for a single browsing context (the active tab and no others, for example). Are there any use cases for which ambient light sensation is needed for a tab that is not active?
* Fuzzing of the timing of ambient light events.
* Note to implementers that Ambient Light may also imply Idle status, and so should have the same permissions.

2) The specification notes that granularity of event firing is left up to the implementation. If events are fired very frequently, could JavaScript fingerprint the user/device based on ambient light patterns? (TLR noted this earlier.) (I learn what sensor your device has because the event updates are always separated by multiples of 413 milliseconds. I learn which user this is because you have a habit of pulling your phone out of your pocket once every hour.)

Potential mitigations:
* Limiting granularity of timing or fuzzing of the timing of ambient light events.
* Limiting granularity of values (already done -- only three values makes this less of a concern).

3) Does the light sent out by the device's screen (or, for that matter, another screen near by) change the ambient light value of the sensor? If so, one could imagine communicating between unrelated web pages by alternating the screen white and black and reading the changing (high-low-high) ambient light values, through visual morse code. (Yes, I fully admit this is far-fetched, but perhaps trained by security reviews, I think it's valuable in brainstorming all possible attacks.)

Potential mitigations:
I'm not sure any are necessary, but limiting ambient light events to the active tab or limiting/fuzzing the timing would mitigate the attack, if there is one.


Regarding atomicity, I agree that many of the privacy concerns we discuss are going to go across specs. Even the ones I've listed here where I tried to be ambient-light specific may apply to any sensor that provides background event updates. Any API that provides real-time updates to background tabs from a device sensor could be used to correlate a user's identity across browsing contexts. (I believe we didn't discuss this with Geolocation, and perhaps we should have.)

As I noted on last month's PING call, there are also privacy concerns that only arise in the use of multiple APIs. A device can be fingerprinted, or multiple users on multiple devices can be co-located, based on the combined values from many different sensors, even when the info from any single sensor is innocuous and not fingerprintable.

I would note that one reason we're doing atomic reviews of these APIs is that the APIs are themselves atomic. I don't know the full history of that decision; but as Erin noted, these were split off of the larger Sensor API. It might be that DAP or PING could come up with generalized advice for privacy considerations of device sensor APIs, but we would still want those generalized considerations noted within each atomic spec -- if this is genuine guidance (or even specific requirements) for the implementer, the implementer should be able to read it in the single spec that she is in the process of implementing.

Also, +1 on compiling a checklist; even if we decide that the comments we have on any single atomic spec would be better as generalized guidance, we as a group can learn from the concerns we identify in coming up with a process for identifying privacy concerns across specs in general.

Received on Saturday, 12 January 2013 04:12:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:49:24 UTC