Fwd: Ambient Light Events review [retitled]

A very big thank you to Erin for her review of the draft Ambient Light Events specification.

We will be discussing and consolidating the comments/reviews of this draft specification and the Proximity Events specification on the call on Thursday 24 January 2013 at UTC 17.

Christine and Tara

Begin forwarded message:

> From: Erin Kenneally <erin@elchemy.org>
> Date: January 21, 2013 9:21:45 AM GMT+08:00
> To: Christine Runnegar <runnegar@isoc.org>
> Subject: Re: Proximity Events and Ambient Events - Consolidated comments from Microsoft
> Reply-To: erin@elchemy.org
> 
> Christine-
> 
> Here is my review... I am in general agreement with the feedback I've
> seen so far, ie, Nick and Tony.
> 
<snip>
> 
> INFORMAL PRIVACY INTEREST GROUP (PING) REVIEW
> 
> Ambient Light Events [1]
> 
> Date: 21 January 2013
> 
> I: Specific privacy-supporting features:
> Lightlevel event value granularity is abstract enough so as to not be
> identifiable.
> 
> II: Privacy risks and vulnerabilities:
> - None inherent to ambient light data itself. It is not a first-order
> identifier for either user or device.
> 
> - Any privacy risk would arise as part of a collective risk with other
> sensor data or contextual information.  IOW, ambient light data are
> contributory to inference or linkage risks derived from combination with
> external data (including other temporal and/or spatial lightlevel api
> data could be aggregated to evolve into an identifier), ie, device
> context information.  This is a 'mosaic risk' wherein the privacy risk
> does not lay with the individual pieces but with the larger picture.
> This risk would generalize across other Sensor API risks, such as idle
> API or other background event APIs.
> 
> III: How the privacy risks and vulnerabilities are addressed and/or
> suggestions as to how to address them:
> - De-couple the timing of ambient light event firing from other
> activity/events such that knowledge of one would not proxy a join to the
> other (this may be a long-winded way of describing others' comments (ie,
> Nick, Tony) re: "fuzzing of the timing of ambient light events"?)
> - Abstract the Value granularity  (currently in the spec)
> 
> - Include considerations of the collective risk of combined sensor
> values within each sensor spec.  Although, I don't know that that alone
> offers much guidance other than "be aware", so we should be careful to
> avoid guiding language that just kicks the can down the road.  Since the
> combination of event variables that would implicate this risk could be
> quite numerous, and future-proofing use cases may be similarly
> intractable, perhaps a general warning is the most practicable guide?
> 
> IV: Suggested text for a Privacy Considerations section in the
> specification:
> (see III comments)
> 
> V: Additional comments:
> ________________________
> Dear volunteers,
> 
> A reminder that the review is due on 17 January 2013. In case you do not
> have an almost complete draft ready to go, let me suggest we extend the
> time to UTC 23 on Monday 21 January so that there will be time for
> feedback from other PING members prior to the call on 24 January 2013.
> The review needs to be complete by 25 January 2013.
> 
> Nick's recent email [1] provides a good starting point for drafting a
> privacy review of the draft Ambient Light Event specification [2].
> There has also been some discussion on the email list.
> 
> In terms of structure, one approach might be:
> 
> -------
> 
> 
> 
> On 1/16/13 2:28 PM, Christine Runnegar wrote:
>> Dear volunteer reviewers,
>> 
>> Tony has some additional comments from Microsoft to contribute. He has
>> helpfully consolidated them into one email.
>> 
>> Please see below.
>> 
>> Begin forwarded message:
>> 
>>> *From: *"Tony Rahman (LCA)" <tonyr@microsoft.com
>>> <mailto:tonyr@microsoft.com>>
>>> *Date: *January 17, 2013 8:12:07 AM GMT+10:00
>>> *To: *Christine Runnegar <runnegar@isoc.org <mailto:runnegar@isoc.org>>
>>> *Subject: **Consolidated comments from Microsoft...*
>>> 
>>> Hi Christine, here are our consolidated review comments for you…
>>> 
>>> Proximity Events draft review
>>> http://www.w3.org/TR/2012/WD-proximity-20121206/
>>> 
>>>  Comments on Privacy and Security areas:
>>> 
>>>  1. There should be a way for a device to refuse to be queried about
>>> its proximity or even presence (e.g. Bluetooth device).
>>> 
>>>  2. Can an object (being queried) be also a hosting device? If so, is
>>> it possible that DeviceProximityEvent and UserProximityEvent
>>> interfaces can be used to do "daisy-chain" queries to find not just
>>> the first device within the proximity, but also the what's in
>>> proximity to the queried device and so on. That needs to taken into
>>> consideration. This is including the ability for devices to see how
>>> far away they are from each other.
>>> 
>>>  3. Perhaps the device should have a max number of queries on itself
>>> allowed within a certain amount of time, and if it's exceeded it will
>>> stop responding to the hosting device for x amount of time (e.g. no
>>> more responses to that host for an hour). This is more of a Security
>>> issue.
>>> 
>>> 4. In isolated usage, there may not be much risk here. However, when
>>> combined with other features such as identity or location I feel this
>>> could be very concerning.
>>> 
>>> 5. There should be a mechanism to alert the user when the feature is
>>> enabled or being used.
>>> 
>>> 
>>>  Ambient Light Events draft review
>>> http://www.w3.org/TR/2012/WD-ambient-light-20121213/
>>> 
>>>  Comments on Privacy and Security areas:
>>> 
>>> 1.       See #1 comment above for Proximity Events (refuse to report)
>>> 2. See #3 comment above for Proximity Events (limit queries) 3. The
>>> real-world usage of any of the Ambient Light Events features must be
>>> strictly controlled as there are privacy and physical security
>>> implications especially when used in a home automation situation. Only
>>> designated/authorized users can query whether it's dark in your house,
>>> etc.
>>> 2.       Hacking is a huge risk here.  This feature could be used in
>>> an unexpected way, e.g. to see if two devices are in the same place
>>> depending how sensitive the light sensor is.
>>> 
>>> 
>>> CSG: <http://sharepoint/SITES/CAT/> Technical Engagement & Strategy
>>> 	
>>> Sr. Program Manager. CIPP/US
>>> 	
>>> tonyr@microsoft.com <mailto:tonyr@microsoft.com>  ( 425.703.2680
>>> 
>>> 
>>> 
>> 
> 
> -- 
> Erin E. Kenneally, M.F.S., J.D.
> CEO, Founder
> eLCHEMY, Inc.
> 8677 Villa La Jolla Dr., #1133
> La Jolla, CA  92037
> www.elchemy.org
> 
> 
> This email message is for the sole use of the intended recipient[s] and
> may contain privileged information.  Any unauthorized review, use,
> disclosure or distribution is prohibited.  If you are not the intended
> recipient, please contact the sender by phone or reply email and destroy
> all copies of the original message.
>

Received on Wednesday, 23 January 2013 23:11:07 UTC