W3C home > Mailing lists > Public > public-privacy@w3.org > October to December 2012

Re: PING - please volunteer - Ambient Light Events

From: Joseph Lorenzo Hall <joe@cdt.org>
Date: Thu, 20 Dec 2012 07:03:05 -0500
Message-ID: <50D2FE79.8090602@cdt.org>
To: Thomas Roessler <tlr@w3.org>
CC: hannes.tschofenig@nsn.com, erin@elchemy.org, public-privacy@w3.org, wilton@isoc.org, ian.oliver@nokia.com
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:03:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 20 December 2012 12:03:40 GMT