RE: PING - please volunteer - Ambient Light Events

So, if I were to use this API other than the data accessible via this, what could I expect from the underlying infrastructure?

t.

Ian

Dr. Ian Oliver
Security, Privacy & Continuity Team
Nokia Location & Commerce


-----Original Message-----
From: ext Joseph Lorenzo Hall [mailto:joe@cdt.org] 
Sent: 20 December, 2012 14:03
To: Thomas Roessler
Cc: hannes.tschofenig@nsn.com; erin@elchemy.org; public-privacy@w3.org; wilton@isoc.org; Oliver Ian (Nokia-LC/Espoo)
Subject: Re: PING - please volunteer - Ambient Light Events

Thomas, there does seem to be something to that approach... I'll mull it over as we close for the holidays for a week or so. best, Joe

On Thu Dec 20 05:18:57 2012, Thomas Roessler wrote:
> So, here's one thought.
>
> The specification leaves the granularity of the event to the 
> implementation.  For most intents and purposes, we probably think of 
> an ambient light as something that changes relatively slowly, and is 
> only triggered every few seconds -- e.g., a cloud moves over the sun, 
> light is turned on or off, ...
>
> What if an ambient light sensor is able to trigger very quickly?  Any 
> risk of opening high-volume side channels or data leaks if we can get, 
> say, 1,000 ambient light sensing events per second?
>
> On the "context dependent" risks -- any that the specification should 
> discuss in its privacy considerations?  E.g., "if you use this in 
> context foo, you may be creating that sort of risk, be aware and act 
> accordingly"?
>
> --
> Thomas Roessler, W3C <tlr@w3.org <mailto:tlr@w3.org>> (@roessler
> <http://twitter.com/roessler>)
>
>
>
> On 2012-12-20, at 10:53 +0100, <Ian.Oliver@nokia.com 
> <mailto:Ian.Oliver@nokia.com>> wrote:
>
>> This particular spec/API in the form here has no privacy aspects at 
>> all. If there are then it will be buried down in the infrastructure 
>> supporting such an API/Spec and thus be out of scope and highly 
>> context dependent. You could construct an artificial example where a 
>> continuous stream of light readings is taken and then combined with 
>> other data to “fingerprint” a user, but to obfuscate or anonymised 
>> this particular stream of information you’d just have to put your 
>> device in your pocket.
>>
>> So, I’m in fully agreement with Hannes and other in that it is not 
>> meaningful to review such specifications in isolation.
>>
>> For me this highlights one of the areas where we’re going wrong wrt.
>> Privacy in that much review and auditing is made without appreciating 
>> the context and semantics of the information.
>>
>> t.
>>
>> Ian
>>
>>
>>
>> *Dr. Ian Oliver*
>> Security, Privacy & Continuity Team
>> Nokia Location & Commerce
>>
>> *From:* ext Tschofenig, Hannes (NSN - FI/Espoo) 
>> [mailto:hannes.tschofenig@nsn.com <http://nsn.com>]
>> *Sent:* 18 December, 2012 16:17
>> *To:* erin@elchemy.org <mailto:erin@elchemy.org>; 
>> public-privacy@w3.org <mailto:public-privacy@w3.org>
>> *Cc:* wilton@isoc.org <mailto:wilton@isoc.org>
>> *Subject:* 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
>> ---------------------------------------------------------------------
>> ---
>>
>> *From: *ext Erin Kenneally
>> *Sent: *12/18/2012 3:56 PM
>> *To: *public-privacy@w3.org <mailto:public-privacy@w3.org>
>> *Cc: *wilton@isoc.org <mailto: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 <http://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> <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.
>>
>

--
Joseph Lorenzo Hall
Senior Staff Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
joe@cdt.org
PGP: https://josephhall.org/gpg-key

Received on Thursday, 20 December 2012 12:25:26 UTC