PING call - informal chairs summary - 28 February 2013

Informal chairs' summary – 28 February 2013
 
Thanks to our visiting scribe, Manu.
 
Next call on 28 March 2013 (same time in the US and one hour earlier in Europe)
 
--------
 
* Completed action items:
 
- Privacy reviews - Proximity Events and Ambient Light Events
 
Thank you reviewers!
 
* New action items:
 
- Privacy review: Encrypted Media Extensions [to be led by Rigo Wenning]
- Gathering list of questions arising during privacy reviews [Nick Doty to provide a thread link, with Hannes Tschofenig]
 
* Ongoing action items:
 
- 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.
 
* Encrypted Media Extensions [1]
 
Thank you Mark Watson, Manu Sporny and others from the HTML WG for joining the PING call for this discussion.
 
Introduction (Mark Watson)
 
Currently, plug-ins (e.g. Microsoft Silverlight; Adobe Flash Player) are used to deliver DRM-protected content to users via the browser. The objective of EME is to provide a common approach to content protection using HTML5 natively.
 
Through EME, the functionality of Content Decryption Modules (CDMs) could be more constrained than under the plug-in approach. Note: the user agent developers would bear the responsibility to build in the constraints (e.g. privacy-protecting elements).
 
The proposal does not define Digital Rights Management system (DRM) or a type of encryption module, but rather it proposes a uniform API that could be used by Javascript applications. It allows messaging to be mediated via the browser to a JavaScript Web application. This enables functionality such as authentication and authorisation to be done by the application rather than the CDM.
 
In response to a query as to how a user would be able to verify or audit what is being communicated via the DRM, Mark Watson explained that he does not expect that browser vendors would provide an open API for user-initiated CDMs. However, if they did, it would be a matter for the implementors to decide if it is appropriate to provide this functionality.
 
Regarding a question about whether the API would communicate with secured memory, Mark Watson explained that there are DRM solutions based on “trusted” execution environments (TVs, mobile devices), but that exactly what the CDMs do in this respect is out of scope for the specification.
 
Adding to Mark Watson’s explanation, Adrian Bateman suggested that it is not helpful to dwell on the plug-in vs. browser approach, and that many of the questions raised are good questions for implementers. Further, the goal of the specification is to provide a common approach to content protection using HTML5 natively. The expectation is that multiple browsers would support CDMs and that the ISO common encryption standard would be used so that the same media would be playable in different browsers even if they support different CDMs.
 
Mark Watson also added that the specification is an improvement on the current situation.
 
Some potential privacy concerns were raised:
 
- the draft specification does not provide for notice to the user as to what information is being communicated from his/her device to the CDM, or even the fact that information is being communicated;
 
- there is potential for device (and therefore, user) tracking – for example: if a user’s device has been assigned a symmetric key pair that enables the CDM to decrypt what it has sent, the CDM may be able to uniquely identify and track the device over multiple sites;
 
- abdication to the CDM - the browser has to trust the CDM because it has no way to verify what the CDM is or is not communicating, storing, and whether or not CDMs are communicating across sites;
 
- an unresolved issue with respect to how the DNT header will communicate with the CDM, how the CDM would interpret that information, and how the CDM response could be verified;
 
Some views/proposed solutions:
 
If the CDM is communicating personal data or enabling identification or correlation, then to keep the current properties of the Web platform, there would need to be geo-location style user authorisation.
 
Data communicated between the browser and the CDM could be labelled with metadata that is then accessible to the user through a dashboard.
 
Perhaps some guidance to implementers (including UAs and CDM providers) would be helpful in the specification itself.
 
Note: the HTML WG requested that input be provided via Bugzilla. In this regard, Bug 20965 [2] concerns the addition of language to a privacy considerations section of the spec suggesting steps that CDM implementers should take to protect privacy.
 
Rigo Wenning kindly agreed to lead a privacy review of EME.
 
We noted some flexibility on the timeline; while input is always welcome at the earliest stages possible, this document would just now be going to its First Public Working Draft.
 
* TAG Privacy by Design document
 
Thank you to Ashok Malhotra for joining the PING call to introduce this document. Unfortunately, the EME discussion consumed most of the hour, however, in the last minutes of the call, we decided to assign Nick to review how best to use the document in the development of the Privacy Considerations document.
 
[1] https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20965
 
* Privacy considerations and privacy reviews
 
Frank Dawson agreed to be an editor for a process document for privacy reviews for W3C specifications and Nick Doty agreed to be an editor for the privacy considerations document based on fingerprinting and the existing TAG Privacy document.
 
Link to the minutes:  http://www.w3.org/2013/02/28-privacy-minutes

Christine and Tara

Received on Wednesday, 13 March 2013 11:06:50 UTC