RE: PING - please volunteer - Ambient Light Events

I think that this spec illustrates quite nicely how useless it is to deal with privacy at the level of each individual specification. 

Hannes

Sent from my Windows Phone

-----Original Message-----
From: ext Erin Kenneally
Sent: 12/18/2012 3:56 PM
To: public-privacy@w3.org
Cc: wilton@isoc.org
Subject: Re: PING - please volunteer - Ambient Light Events

I was able to quickly read through the spec wrt privacy and security
implications, precisely because it is an extract of the larger more
complicated Sensor API which in and of itself raises no reasonable
concerns.  The capability *potential* does indeed raise privacy &
security issues, but the segregation of specific events (ambient light
being the one in this instance) for implementation simplicity also
allows precise identification/exclusion of p&s issues.  So, while
Robin's comments about capabilities will prove to be pertinent in the
review of other components of the aggregate spec, I think we need to be
mindful not to lose sight of the impacts of the interaction between
individual specs... and that can only be done when all components are at
the table.

/erin

-- 
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
On 12/18/12 5:21 AM, Robin Wilton wrote:
> I have the following comments on Section 4 - Security and privacy
> considerations:
> 
> 1 - I fully appreciate the point, made elsewhere about security &
> privacy considerations for specifications in general, that if a spec
> raises no security & privacy concerns beyond the "normal, generic" ones,
> there's little benefit in re-stating them in every spec.
> 
> 2 -  That said, I think it's just worth noting the following and then,
> probably, moving on:
> 
>   * In itself, an Ambient Light event handling spec raises no specific
>     privacy/security concerns, but in combination with other kinds of
>     data, ambient light data could conceivably have privacy/security
>     implications; 
>   * The kind of device that contains photosensors/similar detectors and
>     is capable of implementing such a spec can also reasonably be
>     expected to have capabilities for network communication and
>     geo-location, and possibly also image/sound capture. etc.;
>   * Therefore, although ambient light data in itself is not a
>     privacy/security concern, it's reasonable to assume that it will be
>     present in conjunction with networking and geo-location
>     capabilities, and that a device could be remotely instructed to
>     report other data (such as location, images, sound, etc.) in
>     response to an ambient light event;
>   * This raises the normal set of concerns about whether such behaviour
>     is evident to the user, whether user consent and control are a
>     factor, auditability and transparency of the use of such data, and
>     so on.
> 
> 
> I know these are more to do with the application that *uses* the ambient
> light capability than the ambient light capability itself, so as I say,
> this is mainly me throwing in my privacy 2c-worth. Having done so for
> this spec, I'll try and restrain myself for other specs ;^)
> 
> All the best,
> 
> Robin
> 
> Robin Wilton
> Technical Outreach Director - Identity and Privacy
> Internet Society
> 
> email: wilton@isoc.org <mailto:wilton@isoc.org>
> Phone: +44 705 005 2931
> Twitter: @futureidentity
> 
> 
> 
> 
> On 18 Dec 2012, at 07:46, Christine Runnegar wrote:
> 
>> Dear all.
>>
>> We are looking for 3 (or more) reviewers.
>>
>> 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.
>>
>> P.S. The specification is short (only about 2 pages).
>>
>> Please volunteer!
>>
>> Christine and Tara
> 




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.