Re: PING - please volunteer - Ambient Light Events

I don't know, maybe rephrase your question? best, Joe

On Thu Dec 20 07:24:25 2012, Ian.Oliver@nokia.com wrote:
> 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
>
>

--
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:58:47 UTC