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


thanks for reviewing this. Comments/proposal inline.

regards, Frederick

Frederick Hirsch

On Jun 8, 2013, at 11:32 PM, ext Rigo Wenning wrote:

> Hi Frederick, 
> I have one further remark on the proximity privacy considerations. For 
> the moment, the fingerprinting effect is mostly put forward. 
> IMHO, an even bigger risk of proximity events is that the location of 
> the object in proximity is known and thus the application or service may 
> derive location information from the presence of the object. This is 
> very sensitive in many directions. On the one hand it may be a privacy 
> risk for the user that he is proven to be in a certain location and we 
> should alert application developers that sharing this location 
> information may be very problematic. 

I think we may be making different assumptions.

I suggest proximity in this case does not refer to NFC or any active method of exchanging information, but rather a sensor on the device that notes if 'something' is in extremely close proximity.

Thus there does not seem to be ability  to correlate *what* is in proximity and only that something is close. The only location information thus is the device location services (GPS) which is a separate issue.

I do not understand how it is possible to "derive location information" from the presence of an object in extreme close proximity. Sure if it were meters one could perform indoor mapping with much data (if and when maps were available that could distinguish based on where the coffee machine is, being humorous) but that  is not the case here.

Likewise I do not see how this API can be used to prove location.

Clearly there is an impact on the risk analysis based on the maximum distance the proximity sensor enables, which in this case is small. If it were large then there could be a risk. If there were active communication of data there would be a risk.

The informative introduction states: "The DeviceProximityEvent interface provides web developers information about the distance between the hosting device and a nearby object."

yet nowhere do we define "nearby" - maybe we should, or maybe we need a sentence in the security considerations section on the need for 'nearby' to be less than say a an few centimeters?

how about we change this sentence to state:

"The DeviceProximityEvent interface provides web developers information about the distance between the hosting device and a nearby object, within a few centimeters."

Would this address the concern? (and others in DAP, would it still be accurate or is the maximum distance open-ended)

> On the other hand, the user's presence in some location may be a 
> significant defense if being accused of things that happened at the same 
> time at a different location. 
> As usual, the remedy is to put things under user control. This means 
> that it is IMHO not an issue to store the location information of the 
> proximity event into the device itself. But if location sharing is 
> desired, the usual precautions should be taken, namely user agreement 
> and some level of indication of sharing in the user interface. 

In this case I suggest user control might consist of restricting the maximum distance the sensor can work at, but I think this might be more applicable for other sensor work, perhaps in SysApps.

> --Rigo
> On Sunday 19 May 2013 16:01:36 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? * 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, 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.
>>> 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

Received on Wednesday, 10 July 2013 21:34:50 UTC