Re: [light, proximity] Proposed privacy considerations text for Proximity Events and Ambient Light Events specs

Thanks Nick, some comments in line, prefixed by <FH>.

I also include a proposed update to the privacy considerations text as well as proposed changes to the normative event sections that will require some WG agreement.

A. Here is update to the privacy considerations text.

The following proposed text is common to both specifications, apart from the part marked [SPECIFIC] which should be replaced with the specific text that follows.

Proposed Common text:
---

4. Security and Privacy Considerations

This section is informative.

Privacy threats can arise when this specification is used in combination with other functionality or when used over time, specifically with the risk of correlation of data and user identification through fingerprinting. Web application developers  using these Javascript APIs should consider how this information might be correlated with other information and the privacy risks that might be created. The potential risks of collection  of such data over a longer period of time should also be considered.

[SPECIFIC]

If the same Javascript code using the API  can be used simultaneously in different window contexts on the same device it may be possible for that code to correlate the user across those two contexts, creating unanticipated tracking mechanisms.

Browser implementations should consider providing the user an indication of when the sensor is used and allowing the user to disable sensing.

Web application developers that use this specification should perform a privacy assessment of their application taking all aspects of their application into consideration.

---

[SPECIFIC] to be replaced with the following for Proximity Events:

Variations in implementation limits of  minimum and maximum sensing distance as well as event firing rates offer the possibility of fingerprinting to identify users. Browser implementations may reduce the risk by limiting the granularity and event rates available to web application developers.

[SPECIFIC] to be replaced with the following for Ambient Light Events:

Variations in implementation light level values as well as event firing rates offer the possibility of fingerprinting to identify users. Browser implementations may reduce the risk by only using the less precise LightLevelState of 'dim', 'normal', and 'bright' and limiting event rates  available to web application developers.

---

B. Here is proposed normative text to add related to events (refer to editors drafts)

Proximity section 5.1

change
"When the current device proximity changes, the user agent must queue a task to fire a device proximity event at each browsing context's Window "

to
[[ When the current device proximity changes, the user agent must queue a task to fire a device proximity event at the browsing context's Window. Note that the implementation SHOULD NOT fire a device proximity event in multiple browsing contexts to avoid the privacy risk of correlation of context information.  For example, a mobile device might only fire proximity event for the active "tab". ]]

Likewise for light in section 5.1

change
"When the current light level changes, the user agent must queue a task to fire a device light event at each browsing context's Window."

to

[[ When the current light level changes, the user agent must queue a task to fire a device light event at the browsing context's Window. Note that the implementation SHOULD NOT fire a device light event in multiple browsing contexts to avoid the privacy risk of correlation of context information.  For example, a mobile device might only fire light event for the active "tab" . ]]

I guess we need to be clear whether it makes sense to have the event for multiple windows vs the privacy consideration.

What do others think?

regards, Frederick

Frederick Hirsch
Nokia



On May 19, 2013, at 7:01 PM, ext Nicholas Doty wrote:

> Thanks, Frederick, for drafting this text and turning the Privacy Interest Group comments and questions into coherent specification text. I had a few comments which I've included inline below. At a high-level, I think my questions are:
> 
> * should this be entirely informative or is there a place for normative text?

<FH>  to date we've received feedback from browser implementers that this should be informative - leaving it to implementations to decide how to protect privacy and to what degree - a  competitive differentiator if you will.
I thought I'd make this explicit so we are all on the same page. I'm not sure how you would interop/conformance test this as normative material, for example.

> * should the specification describe any concept of "personal information"?

<FH> I think this is out of scope of the task of the specification

> * which considerations are intended for implementers vs. application developers?

<FH> some items clearly belong to application developers (e.g. web sites using javascript), others are relevant to the browser implementation , so both are target audiences, clarified in proposed text above

> * is ranking of different fingerprinting techniques useful?

<FH> Not in these specifications per se, though a reference might be helpful.

> 
> CCing public-privacy both because they might want to see the specific results of a privacy review and they may have insight into these questions.
> 
> On May 9, 2013, at 11:22 AM, Frederick.Hirsch@nokia.com wrote:
> 
>> I have drafted proposed text to add to the currently empty Security and Privacy considerations section of the  Proximity Events [1]  & Ambient Light Events [2] specifications.
>> 
>> This proposal is based on feedback from the privacy interest group (PING) [3], [4], [5].
>> 
>> The following proposed text is common to both specifications, apart from the part marked [SPECIFIC] which should be replaced with the specific text that follows.
>> 
>> Proposed Common text:
>> ---
>> 
>> 4. Security and Privacy Considerations
>> 
>> This section is informative.
>> 
>> This specification does not process or link to personal information.  
> 
> I'm not sure the concept of "personal information" is well-defined, and in this case I'm not sure how useful it is. During the review it was occasionally speculated that there may be contexts where the ambient light or proximity revealed information about a person they might want to keep private -- does that make information "personal"? Furthermore, I would suggest that such a sentence is not particularly useful to the reading audience.
> 

<FH> I meant clear personal information such as account numbers, etc, not context information which is harder to make use of. That said, I'm happy to remove this sentence, see revised text.


>> Privacy threats can arise when this specification is used in combination with other functionality or when used over time, specifically with the risk of correlation of data and user identification through fingerprinting.  Application developers should consider how this information might be correlated with other information and the privacy risks that might create. The potential risks of collection  of such data over a longer period of time should also be considered.
> 
> By "application developers", do you mean implementers (like browser vendors) of this API? Or JavaScript web app authors who will make use of the API?

<FH> I meant Javascript authors, see revised text.

> I think the question of correlation risk over time is one for implementers -- application developers might take advantage of that correlation, but it wouldn't be an inadvertent outcome that they would need to consider for downstream use, I don't think.

<FH> I would not expect it to be in the interest of a browser vendor to mount an attack, as trust is core to browser adoption.

> 
>> [SPECIFIC]
>> 
>> If the same Javascript code using the API  can be used simultaneously in different window contexts on the same device it may be possible for that code to correlate the user across those two contexts, creating a new kind of tracking 'bug'.
> 
> Rather than 'bug', I would say "a new kind of unexpected correlation, which could be used for tracking a user's activity". Furthermore, this seems like an area where we might usefully add normative text:

<FH> see revised text
> 
> Implementations SHOULD NOT fire [ambient light / proximity] events in multiple browsing contexts. For example, a mobile device might only fire proximity change events for the active "tab".
> 
> Normative text might be appropriate here because this would standardize a mitigation of the privacy threat for all implementations and give consumers of the API clarity that they shouldn't expect background tabs to receive such events.

<FH>  This should then go into the normative section on events.

> 
>> Implementations should consider providing the user an indication of when the sensor is used and allowing the user to disable sensing.
>> 
>> Application developers that use this specification should perform a privacy assessment of their application taking all aspects of their application into consideration.
> 
> While I think this is sound advice for application developers generally, is it productive to add to this section of this specification?

<FH>  I think it is helpful, yes.

> 
>> ---
>> 
>> [SPECIFIC] to be replaced with the following for Proximity Events:
>> 
>> Variations in implementation limits of  minimum and maximum sensing distance as well as event firing rates offer the possibility of fingerprinting to identify users, although this threat is relatively low considering the availability of other simpler  fingerprinting possibilities. Implementations may reduce the risk by limiting the granularity and event rates.
> 
> Is it important to describe the fingerprinting threat as low because of other fingerprinting possibilities? I am particularly concerned because if every specification includes this caveat, it could give the impression that no fingerprinting mitigations are ever worth pursuing. (There are some who have advocated for accepting that outcome, but it seems to be an open and changing question.) If some of the simpler fingerprinting techniques were mitigated in other specs or common browser implementations, would we need to update this spec to note that this fingerprinting technique is now a relatively large threat? I'm also not sure that the judgment of the relative threat of fingerprinting in implementing this specification is important to the implementing audience.

<FH>  ok, we can leave the judgement to others. see revised text.

> 
> Thanks,
> Nick

Thanks for taking the time for careful review Nick.

Received on Monday, 20 May 2013 14:28:09 UTC