RE: draft, pls review by Tuesday - Summary of Privacy Interest Group (PING) feedback regarding Proximity and Ambient Light APIs

Thank you drafting this up.

Could I suggest also noting:

* Reviewing specifications in isolation is often inadequate to assess the privacy issues.  For example, a sensor input is not a privacy concern on its own, but only when combined with methods that allow the state to be covertly leaked, or when combined with standards and UI's that mis-direct the users attention from the concerns.

* 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.

* Dependence on secure script context support: The lack of support for secure scripting contexts is a common problem across many specifications and should be a priority and specifications that expose private state should be deferred until this is resolved.

* 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.

cheers
Fred


> From: Frederick.Hirsch@nokia.com
> To: public-privacy@w3.org
> CC: Frederick.Hirsch@nokia.com
> Date: Thu, 7 Feb 2013 23:17:17 +0000
> Subject: draft, pls review by Tuesday - Summary of Privacy Interest Group  (PING) feedback regarding Proximity and Ambient Light APIs
> 
> Here is my draft summary of the PING Ambient Light and Proximity review, based on the emails, IRC log and my recollection of the call.
> 
> Please let me know of any additions, corrections etc before I send to the DAP list on Tuesday, 12 Feb.
> 
> regards, Frederick
> 
> Frederick Hirsch, Nokia 
> 
> [[
> 
> 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)
> 
> 3) There are possibilities for fingerprinting based by event patterns during and over time.
> 
> 4) 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
> 
> 5) 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.
> 
> 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 though again I think this might be lower priority than other possible concerns.
> 
> 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 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
> 
> 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
> 
> ]]
> 
>