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

On the concept of 'personal information', I have wondered about two layers:

* personally derived information (PDI):  information that derives from the interaction with a single user (or their UA or device)
* personally identifiable information (PII): information that can be related to a specific user (or their UA or device)

I think once you keep any PDI, you risk it being or becoming PDI (e.g. after re-identification), and that specifications should start talking about exercising care with the amount and nature of PDI that is exposed, retained, etc.


On May 19, 2013, at 16:01 , Nicholas Doty <npdoty@w3.org> 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?
> * should the specification describe any concept of "personal information"?
> * which considerations are intended for implementers vs. application developers?
> * is ranking of different fingerprinting techniques useful?
> 
> 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.
> 
>> 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? 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.
> 
>> [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:
> 
> 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.
> 
>> 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?
> 
>> ---
>> 
>> [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.
> 
> Thanks,
> Nick

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Monday, 20 May 2013 16:18:35 UTC