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

Re: Custom and extending CDM to support other DRM systems

From: Mark Watson <watsonm@netflix.com>
Date: Sat, 7 Feb 2015 09:39:51 -0800
Message-ID: <4409845144482171656@unknownmsgid>
To: Emmanuel Poitier <emmanuel.poitier@enman.fr>
Cc: János Barta <bartakok@gmail.com>, "public-html-media@w3.org" <public-html-media@w3.org>
Sent from my iPhone

On Feb 7, 2015, at 8:13 AM, Emmanuel Poitier <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
> 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> wrote:
>
>>
>> On Fri, Jan 30, 2015 at 7:49 AM, Emmanuel Poitier <
>> 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.

-    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 ?

...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 17:40:22 UTC

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