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

Re: Custom and extending CDM to support other DRM systems

From: Emmanuel Poitier <emmanuel.poitier@enman.fr>
Date: Tue, 14 Apr 2015 21:28:16 +0200
Message-ID: <552D6A50.4010902@enman.fr>
To: public-html-media@w3.org
All,

I think my concern was already addressed and the discussion in BugZilla 
for the bug 20944 (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944) 
gives enough confidence that other people also care about 
interoperability between UA.

Le 09/02/2015 10:58, János Barta a écrit :
> On 2015.02.08. 0:48, Mark Watson wrote:
>>
>>
>> On Feb 7, 2015, at 1:09 PM, János Barta <bartakok@gmail.com 
>> <mailto:bartakok@gmail.com>> wrote:
>>
>>> 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.
>>
>> And to me option 1 sounds better because it is the option which 
>> allows us to avoid site-specific downloads. Yes, this comes at some 
>> cost to the service providers who must support multiple DRMs, but it 
>> is the service providers rather than the users who stand to benefit 
>> so surely they should bear the costs, rather than the users ?
>>
>> ...Mark
>>>
> Which is the bigger trauma from the user point of view: if they need 
> to add a new component to their favorite browser or replace the whole 
> UI (even the OS as well in some cases )?
> What about having a default pre-installed CDM which is replaceable in 
> case of need? Yes, there are open questions with the sandbox solution 
> as well (e.g.: protection of media player path) but I do believe that 
> it is a good direction.
>
>
> -Jani
>
>>>
>>> -Jani
>>>
>>>> ...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>
>>>
>

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





Received on Tuesday, 14 April 2015 19:28:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 14 April 2015 19:28:43 UTC