W3C home > Mailing lists > Public > public-html-media@w3.org > February 2015

Re: Custom and extending CDM to support other DRM systems

From: János Barta <bartakok@gmail.com>
Date: Sat, 07 Feb 2015 22:09:17 +0100
Message-ID: <54D67EFD.2050301@gmail.com>
To: Mark Watson <watsonm@netflix.com>, Emmanuel Poitier <emmanuel.poitier@enman.fr>
CC: "public-html-media@w3.org" <public-html-media@w3.org>
On 2015.02.07. 18:39, Mark Watson wrote:
> Sent from my iPhone
> On Feb 7, 2015, at 8:13 AM, Emmanuel Poitier 
> <emmanuel.poitier@enman.fr <mailto:emmanuel.poitier@enman.fr>> wrote:
>> Hi Janos,
>> all you mentioned make sense to me, and I hope to others as well. I 
>> hope it will be considered by UAs and will be addressed accordingly 
>> for the best interest of users and video service providers.
>> Le 01/02/2015 17:37, János Barta a écrit :
>>> Hi Emmanuel,
>>> On 2015.01.31. 17:26, Emmanuel Poitier wrote:
>>>> 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.
> I would have no objection to such an initiative. But someone has to 
> take the initiative to create and generate interest in such an 
> activity and I am not sure who that would be.
> However, I am not sure that it is possible to offer the security and 
> privacy properties required by the specification based only on the 
> information flow across the boundary, so long as some of that 
> information is in DRM-specific, undisclosed, form.
> The sandboxes being employed by some UAs certainly try to do the best 
> job possible there, but UAs still need to know more than that to be 
> sufficiently confident of the properties of the entire system.
>>> do we really need to have a standard CDM solution or wouldn’t it be 
>>> better to focus on a standard, auditable layer amongst browser 
>>> components and  CDM modules (as it is already available in case of 
>>> Firefox), called CDM/DRM sandbox?
>>> In case of a Sandbox solution:
>>> -    CDM-Sandbox can be a “bridge” with well-defined, standard 
>>> interfaces
>>> -    DRM specific CDM can be an independent/closed/proprietary module
>>> -    CDM will be downloaded and activated from the website of DRM 
>>> provider based on user consent
> I think some people would consider this a return to the bad old days 
> of different ActiveX controls for each site. One of the primary 
> motivations for EME from our point of view is that the user is no 
> longer asked to install something: they choose their browser and with 
> that they get all the capabilities they need.
Why do we need to return to the bad old days? I hope we learned from 
past mistakes and we would be able to prepare a better solution.
Regarding the mentioned primary motivation of EME: considering the 
scandal around user privacy probably it would make sense to reconsider 
it. (Sometimes, it is better to ask consent than believe that silence 
gives permission. )
>>> -    Decoupled Browser and DRM layers (-> Multi-DRM support)
>>> -    etc…
>>> I think the biggest issue is that there is no interest from the 
>>> UI/Browser side to have a cross-platform solution. There is no doubt 
>>> about their intention is to set their own CDM in stone (because of 
>>> the additional incomes, e.g.  from licenses).
>>> I would like to believe that it is only my misinterpretation and 
>>> they (Google/Microsoft/Mozilla/Opera/Apple…) are willing to make 
>>> sacrifices in order to have a standard, sandbox based cross-CDM 
>>> solution. We will see…
> You should hunk about it from the users' point of view too, or first. 
> How do installable site-specific CDMs benefit users ?
Yes, definitely, I totally agree with you.
Option 1: browser-dependent service (except when the service provider 
has a multi-KeyServer/DRM env.)
     -> please use/download this particular browser to access your 
service site...
Option 2: cross-browser solution with downloadable CDMs
     -> you can use your favorite browser, but consent is needed to 
download a necessary component

Option2 sounds better to me.


> ...Mark
>>> Best regards,
>>> Janos BARTA
>>> 1. dia
>> 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
>> <emmanuel_poitier.vcf>
Received on Saturday, 7 February 2015 21:09:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:58 UTC