- From: Emmanuel Poitier <emmanuel.poitier@enman.fr>
- Date: Sat, 31 Jan 2015 17:26:38 +0100
- To: Mark Watson <watsonm@netflix.com>
- CC: "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <54CD023E.5070702@enman.fr>
Mark, Le 30/01/2015 16:59, Mark Watson a écrit : > > > On Fri, Jan 30, 2015 at 7:53 AM, Emmanuel Poitier > <emmanuel.poitier@enman.fr <mailto:emmanuel.poitier@enman.fr>> wrote: > > Matt, > > Le 30/01/2015 16:14, Mark Watson a écrit : >> >> >> On Fri, Jan 30, 2015 at 6:58 AM, Glenn Adams <glenn@skynav.com >> <mailto:glenn@skynav.com>> wrote: >> >> >> On Fri, Jan 30, 2015 at 7:49 AM, Emmanuel Poitier >> <emmanuel.poitier@enman.fr >> <mailto:emmanuel.poitier@enman.fr>> wrote: >> >> All, >> >> I am currently looking after the information on how to >> extend the CDM to support other DRM systems, which is >> nowadays fixed and hardcoded for each browsers (IE with >> PlayReady, Chrome with Widevine, Safari with FairPlay). >> It would be nice to ensure the EME spec does provide >> information and also how browsers would support that in >> an agnostic manner to ensure a non fragmented market >> where the user does want to play a protected video >> content whatever the browser he is using. >> >> >> I doubt if anything has changed on this front, but this type >> of specification was ruled out of scope for EME. EME uses the >> term and concept "CDM" only in a notional manner, and does >> not specify any concrete interface to such a component. >> >> It is likely that interface and any mechanism for >> adding/extending UA supplied CDMs will remain UA specific, >> that is, until some organization steps forward to standardize >> it (assuming UA vendors are willing to do that... a dubitable >> proposition). >> >> >> Yes, such an API is not really in scope of W3C, never mind just >> EME. Just as NPAPI for <object> was created by UA vendors any >> such cross-browser CDM API would need to come from the UA >> vendors. Of course, the open source implementations of EME have >> CDM APIs in their code, but a major point of EME was to bring DRM >> under UA control, so I would not expect UAs ever to support >> download of arbitrary user-installable CDMs - at least it's not >> clear to me how this could be done and simultaneously meet the >> privacy and security requirements of the specification. Whilst >> UAs can technically enforce many security and privacy properties >> through sandboxing I'm not sure they will be willing to host CDMs >> about which they have no knowledge whatsoever. >> >> …Mark > > I can understand this point, though a service provider protecting > their content will evaluate DRM systems based on the UA CDM DRM > support before using EME which is at the moment quite split across > browsers. Thanks anyway for your view on this issue. > > > What's your alternative and how does it address the security and > privacy issues ? > > …Mark I would see a separate working group who will be in charge of offering a CDM description with security analysis based on the data flow interfacing with the CDM. It may be a consortium composed of all or the most used DRM providers to design a such component, so they would have a complete knowledge and the necessary technical constraints to ensure the required level of security delivered by the CDM component within the EME feature. It does definitely require a collaborative work to assure content protection and the legitimate use of protected content in a generic manner to let users choose their preferred way to use them. > > > > > Best regards, > -- > Emmanuel Poitier- Chief Executive Officer (CEO) > Enman > > Telephone:+33 (0)2 54 67 15 38 > <tel:%2B33%20%280%292%2054%2067%2015%2038> > Mobile:+33 (0)780 381 124 > Email:emmanuel.poitier@enman.fr <mailto:emmanuel.poitier@enman.fr> > Web site:http://enman.fr > > Best regards, -- Emmanuel Poitier- Chief Executive Officer (CEO) Enman Telephone:+33 (0)2 54 67 15 38 Mobile:+33 (0)780 381 124 Email:emmanuel.poitier@enman.fr Web site:http://enman.fr
Attachments
- application/pkcs7-signature attachment: Signature cryptographique S/MIME
Received on Saturday, 31 January 2015 16:27:37 UTC