PING - informal chairs summary - 28 March 2013

Informal chairs' summary – 28 March 2013
 
Many thanks to Dom for providing us with an excellent overview of getUserMedia as well as identifying some of the associated privacy risks.
 
Thank you Tara and Nick for scribing.
 
Next call on 25 April 2013
 
--------
 
* New action items:
 
- Privacy review of getUserMedia [led by Hannes Tschofenig]
 
* Ongoing action items:
 
- Privacy review: Encrypted Media Extensions [led by Rigo Wenning]
- Gathering list of questions arising during privacy reviews [Nick Doty to provide a thread link, with Hannes Tschofenig]
- Process document for privacy reviews for W3C specifications [Editor: Frank Dawson]
- Privacy Considerations document [Editor: Nick Doty]
 
Volunteers for editors for these documents or help contributing to these action items is requested. Please contact the people noted in brackets to volunteer.
 
*  Media Capture Task Force - getUserMedia API (Dominique Hazael-Massieux from the Media Capture Task Force)
 
Slides: http://www.w3.org/2013/Talks/dhm-ping-gum/
Draft specification: http://dev.w3.org/2011/webrtc/editor/getusermedia.html (getUserMedia API)
 
The getUserMedia API defines a set of JavaScript APIs that allow local media, including audio and video, to be requested from a platform. It is being developed by the Media Capture Task Force, a joint task force between the DAP and WebRTC WGs. The task force expects that it will also be used for screen sharing.
 
Once a Web application gets access through the API, media streams can be used locally (e.g. an application could take a picture of the user with the device’s camera, such as “photobooth”) or they can be sent to a remote party to enable audio/video chat within the browser.
 
By default, the Web application would be able to get access to the media stream. For example, if a WebRTC service lets A talk to B, the operator, in most cases, would get access to the stream. To address this privacy and security vulnerability, the task force is looking to add a more confidential mode, but that option would need to be provided by the service operator and without access to the media stream the operator cannot provide additional features such as mixing and filtering. The media stream is always encrypted end-to-end (with DTLS), however, in the confidential mode, the Web application (which is in fact sitting at both ends of the encrypted stream) cannot access the media stream.
 
One issue with this approach is how to enable the user (or user agent) to determine what is being sent and to whom. The end-point could be a gateway or an attacker. A solution could be to link an identity mechanism (e.g. key exchange between the parties to keep out an intermediary or attacker). Most of the work on this aspect is being undertaken in the IETF [1]. If a service operator opts-in to provide the confidential mode, the browser would display some cue that the mode is extra confidential like the padlock for HTTPS.
 
Access is mediated by consent through the browser. The user can grant access to one or more devices through the browser UI. Once access has been granted, each device will be assigned a unique sourceID that persists across sessions unless cleared by the user. The use case for a unique sourceID is to allow a Web application to start in the same state as the last session (e.g. the positions of multiple cameras in the browser or the state of mixed media streams from different devices with different semantics). (Note: Session persistence cannot be managed by the browser because browsers do not have this knowledge (i.e. it is specific to each application).) To mitigate fingerprinting, the draft specification recommends that the unique sourceID be scoped by origin (i.e. each website gets a different ID) and forgotten when a user asks the browser to remove any trace of past interaction with the said Web site (for example, as is the case with cookies). Is there a more privacy-respecting approach to satisfy the use case?
 
Once access is granted to a single device (e.g. one camera), the Web application would have access to information about all devices. The typical use case for this approach is to allow integration of additional media streams or to change which camera/audio/screen is in use once a media stream has been initiated (e.g. a video chat). To do this, the Web application needs information on the other devices (especially a name that enables the user to easily distinguish between devices) whether or not the user has granted the Web application access to the device. This has privacy implications.
 
Using the API for screen sharing is even more intrusive. This work is still very preliminary. It is likely that there will be restrictions (e.g. whether the Web application can store that the screen was shared).
 
Three categories of identified privacy risks:
-       surveillance: spying using microphone or camera
-       fingerprinting: identifying users through their media capture device characteristics
-       profiling: e.g. estimating a user’s purchasing power through their media equipment
 
There may be more.
 
The task force is trying to mitigate the risk of surveillance through consent.
 
Some of the particular challenges the task force has encountered in developing the API are:
-       how to communicate to the user that they are potentially being recorded
-       how to communicate to the user whether the mode is private (vis-à-vis third parties) and whether or not the service provider has access to the media stream; and
-       finding the right balance between privacy and usability in device management.
 
Communicating information to the user is largely achieved through the UI and is, therefore, something that needs to be solved by the browser vendor rather than through the API. The browser vendors seem willing to add another indicator, but this may not be scalable (i.e. if there are so many indicators that users no longer understand what they mean). Similarly, a UI to show the user which devices access has been granted to has not yet been worked out. This is also thought to be out of scope for the API.
 
The task force needs help from the Privacy Interest Group (and others), specifically:
-       to have someone with a good grasp of privacy to follow the work
-       to help the task force develop the privacy considerations section by providing a list of questions that that section should answer
-       to provide guidance regarding fingerprinting (for this API and for APIs as a whole)
 
It would also be useful to have a series of best practices for implementers for those aspects that our out of scope for the API.
 
Thomas Roessler proposed two questions for consideration via email [2]:
 
1. What is the exact rationale for a media source identifier that is (it seems) supposed to be globally unique and persistent across sessions?  It would be useful to look at the requirements in more detail, and see what the functionality and privacy trade-offs are between low-entropy and high-entropy identifiers.
 
2. Scope of this identifier.  If the identifier is high-entropy, then scoping it by origin is probably insufficient: Instead, you'd want to scope it by origin pair, i.e., origin of the top-level frame, and origin from which the script is executed.  Otherwise, a third party iframe might be able to discover that identifier across multiple first parties, which would generate another readily trackable identifier.
 
Note: The task force hopes to get the specification to last call by June or July 2013. However, the API is already available in a number of browsers (Chrome, Firefox, Opera) so implementations are already being developed and deployed.
 
Additional notes: The media capture work also includes recording captured streams. WebRTC also opens up the possibility of P2P communication across browsers. There may have additional privacy impacts associated with this functionality. P2P communication also raises the issue of possible of back channels for sending data. While the media capture work is most urgent in terms of a privacy review, it would be helpful to have PING’s assistance with these issues as well.
 
Hannes Tschofenig kindly agreed to lead a privacy review of getUserMedia.
 
[1] http://datatracker.ietf.org/wg/rtcweb/
[2] http://lists.w3.org/Archives/Public/public-privacy/2013JanMar/0071.html
 
* Reports and discussion of open action items
 
- Privacy Considerations and Fingerprinting Guidance
 
Nick Doty has started an unofficial draft “Fingerprinting Guidance for Specification Authors”
http://w3c.github.com/fingerprinting-guidance/.
 
Nick is also putting together the list of questions that have already been identified through privacy reviews.
 
Hannes Tschofenig has started work on a preliminary draft “Privacy Considerations for Web Protocols”. https://docs.google.com/document/d/1uFyPErULC0gaYv54yxYqTdlOcQavlLme4SvyGsKCCcI/edit?usp=sharing
 
- EME privacy review – no update provided as Rigo Wenning was not on the call
 
- Privacy review process document – no update provided as Frank Dawson was not on the call
 
Link to the minutes: http://www.w3.org/2013/03/28-privacy-minutes.html
 
Christine and Tara

Received on Friday, 5 April 2013 13:23:28 UTC