- From: Joseph Lorenzo Hall <joe@cdt.org>
- Date: Thu, 20 Dec 2012 07:03:05 -0500
- 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 UTC