Re: PING - please volunteer - Ambient Light Events

Well, there was a story recently that the met police in the UK had recorded mains frequency traces fir years, and given a bootleg recording with mains hum on it, could identify when t was made by matching the variation pattern. So maybe one could work out the same thing from a continuous recording of ambient light...

<http://www.bbc.co.uk/news/science-environment-20629671>

In general I agree.  For some specs security considerations are easy in isolation, and for others privacy in isolation.

But…you call your significant other on a business trip, using an IP telephone and they answer and say that they were asleep. Unfortunately the web app that they are using reports to you that there is a lot of ambient light, and pulsating…(are they in a disco?)

In general, there is a privacy consideration to knowing that the reported light level is not commensurate with other reported, assumed, or claimed, attributes of the remote status. "OK, I am inside the warehouse now, and it's pitch dark." "I am out in the park, enjoying the sunshine." "I am at the symphony/theater." and so on. There are (possibly not major) privacy concerns to allowing a remote system to know this data.

On Dec 20, 2012, at 2:18 AM, Thomas Roessler <tlr@w3.org> 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> (@roessler)
> 
> 
> 
> On 2012-12-20, at 10:53 +0100, <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] 
>> Sent: 18 December, 2012 16:17
>> To: erin@elchemy.org; public-privacy@w3.org
>> Cc: 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
>> 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.
>> 
>