- From: Christine Runnegar <runnegar@isoc.org>
- Date: Thu, 28 Feb 2013 11:18:58 +0100
- To: <Frederick.Hirsch@nokia.com> <Frederick.Hirsch@nokia.com>
- Cc: <public-privacy@w3.org>
Again, many thanks Frederick for taking the lead on providing feedback from PING members to the DAP. And, thank you all the reviewers. This is a good example of the helpful input PING can provide to other groups as they develop specifications. Kind regards, Christine and Tara On Feb 27, 2013, at 8:10 PM, <Frederick.Hirsch@nokia.com> <Frederick.Hirsch@nokia.com> wrote: > I shared the following on the public device APIs mailing list (DAP), thanks for all the comments on the earlier draft. > > ( I did not cross-post) > > Frederick Hirsch > Nokia > > > > Begin forwarded message: > >> From: "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com> >> Date: February 27, 2013 2:07:53 PM EST >> To: W3C Device APIs WG <public-device-apis@w3.org> >> Cc: "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com> >> Subject: Summary of Privacy Interest Group (PING) feedback regarding Proximity and Ambient Light APIs >> >> Members of the Privacy Interest Group (PING) [1] reviewed the Proximity [2] and Ambient Light Event [3] Last Call drafts from a privacy perspective. >> >> The following key points were made in the review process: >> >> 1) Privacy threats can arise when these simple specifications are used in combination with other functionality or when used over time. >> >> 2) User notification and control over use of sensors should be provided (e.g. able to turn them off, or know if they are being used), or perhaps provide the ability for user input in place of the sensor value. >> >> 3) There are possibilities for fingerprinting based by event patterns during and over time. >> >> 4) Reviewing specifications in isolation is often inadequate to assess the privacy issues [7] (also see earlier W3C privacy workshop position paper[8] ). >> >> 5) There should be a summary of privacy information applicable to the various sensors collected in one place (I offered to start a draft) and information may also need to be added to each individual draft >> >> 6) Privacy by design: specifications should be designed with privacy threats in mind. For example, an ambient sensor input could be designed to address a use case of adjusting image contrast without the state being accessible to script contexts that can leak the state. [7] >> >> 7) Reviewing these drafts was useful to PING in order to learn and start creating a checklist and process for other reviews. >> >> In detail, >> >> Nick Doty gave an excellent summary in an email [4] that includes examples: using ambient light sensors in multiple contexts over time to correlate the same user, suggesting the spec be limited to a single active window context. >> Similarly he notes a concern similar to the Idle API risk discussion, see [5]. See Nick's email for details. >> >> Nick noted during the call that there is a chance for gleaning information from light sensors, but not with high, med, low settings, so that is good. Robin Wilton noted [9] a potential privacy threat case related to ambient light sensor correlation, suggesting that ambient light might be used to defeat the separation of personal and work 'mobile phone personas'. (though I ask whether this might require similar code running at the same time on the devices) >> >> Nick and Thomas Roessler also note that there is also a fingerprinting risk based on frequency and timing of event occurrence (though I suggest this might be harder than more straightforward fingerprinting approaches). A possible mitigation is to impose limitations on granularity of information. >> >> Ambient Light could offer a side channel for communication via light generation and detection. >> >> Tony Rahman noted [6] that there might be a security risk if there is no limit to the rate of queries and also suggested that remote sensors offer a greater security risk, though I suggest the current specs are focused on local information. He also noted that perhaps there should be an indication to the user when the sensors are used (I'd say in particular for ambient light). In addition he suggests there should be a way to disable sharing proximity information (or in general various sensor information). >> >> The PING group agreed that there may need to be privacy documentation that spans the variety of sensors noting common concerns - I offered to start drafting a document. Nick suggests that material needs to also be repeated in the individual drafts as well, however I'd suggest a short executive summary might suffice. >> >> Nick started a wiki to collect resources around Privacy Considerations, see http://www.w3.org/wiki/Privacy/Privacy_Considerations >> >> Fred Andrews expressed concern on support for secure scripting contexts [7] and also suggests enabling "lying" as a general approach (as with location), unless I misinterpret the following: >> >> * Specifications should not simply be designed to allow the inputs to be disabled by users, but should be designed to also make the choice private rather than a 'share it or block it' approach, and to ensure that user choice can not be used to discriminate against users. For example, an ambient light sensor input specification should support spoofing, and scripts that access the state should run in a secure context without the capability to leak the state. >> >> I hope this is helpful, and thanks again to the Privacy Interest Group for the review and feedback. >> >> regards, Frederick >> >> Frederick Hirsch >> Nokia >> >> [1] http://www.w3.org/Privacy/ >> >> [2] http://www.w3.org/TR/2012/WD-proximity-20121206/ >> >> [3] http://www.w3.org/TR/2012/WD-ambient-light-20121213/ >> >> [4] http://lists.w3.org/Archives/Public/public-privacy/2013JanMar/0007.html >> >> [5] https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.webapi/7mEN0gSryCk >> >> [6] http://lists.w3.org/Archives/Public/public-privacy/2013JanMar/0010.html and http://lists.w3.org/Archives/Public/public-privacy/2013JanMar/0011.html >> >> [7] http://lists.w3.org/Archives/Public/public-privacy/2013JanMar/0030.html >> >> [8] http://www.iab.org/wp-content/IAB-uploads/2011/03/frederick_hirsch-revised.pdf >> >> [9] http://lists.w3.org/Archives/Public/public-privacy/2013JanMar/0033.html >> > >
Received on Thursday, 28 February 2013 10:19:28 UTC