RE: Proposal: Internet Encrypted Media Extensions

Date: Tue, 28 Jan 2014 22:08:43 -0800
From: watsonm@netflix.com

...

But, can you explain the advantage of the restriction in your proposal that the target device not support a full UA ? How much of the web platform has to be missing from the target device for it to obtain that advantage ?

Many of the advantages are noted in the wiki proposal and most would be compromised if the target device were a web browser, and many advantages would become more compromised by the device being less constrained and more customizable.

The target device or app is not a web platform, it is a limited DRM Internet connected media player.  It would be expected to use some http protocols to communicate with the server, so that it could also be implemented in an EME capable web browser.  It would not expose a JS interpreter, or the DOM, would not load or present HTML content, and it would have a well defined protocol that could be sand-boxed effectively.  It would be required to operate without contact with a web browser.


The proposal is intended to give the user the option to isolate the protected media player from the web page and user agent.


For the purpose of discussion, consider a remote-EME implementation that forwards EME API calls to a remote device  This would have some characteristics of the proposal: the remote application need not be a web browser, and it gives the user the option of separation.  However this would still be objectionable, not limited to: the DRM protocols are still being routed through the web browser; and the open web is still being tainted by DRM APIs.


An open web has significant benefits for the user, and it was never necessary to add the EME API to meet the use case of viewing protected content.


Sure, UAs can - and some have - implement content protection "under the covers" of the <video> element, without ever exposing any additional API to the web page. The UA silently contacts the license server identified in the content using a proprietary DRM protocol. This is much worse from a security and privacy perspective than EME.
 

There are a few separate issues conflated here:

1. A method used to distinguish protected content by the <video> element affect security and privacy. 

The proposal only requires the web browser to detect content to be redirected, and passes the URL to a separate device or app.  This is a well defined declarative mechanism that the user can easily control - the best standard for user security and privacy.

2. 'The UA silently contacts the license server identified in the content'

The proposed media player would only contact the server as requested, and the user can sandbox the device's communication to restrict it to only contacting the server identified in the content.  The proposal supports a market for the media player so that a user can choose one from a reputable vendor.  A much better outcome for security and privacy than the EME.

3. 'using a proprietary DRM protocol'

The proposal defines the http protocol used to contact the server.  This is much better for security and privacy than the EME API which leaves this undefined.

The proposal is defined to be implementable by a user chosen media player web app on an EME capable web browser.  What exactly is 'much worse from a security and privacy perspective than the EME'?


The EME proponents have still not disclosed their requirements

Yes, we have. The requirement is to integrate HTML <video> with existing content protection systems so that users of protected content services can also enjoy the many and varied benefits of web technologies. Ideally, we would also avoid a separate "install" step and enable use of hardware decoding.
 
Last week the requirement was to 'add an EME API'.  We are having to extract the requirements and use cases from the proponents though a slow and ongoing process while you continue to advance your proposal.  On many occasions the proponents have bluntly refused to engage in a process to better define the requirements.

The 'many and varied benefits of web technology' is a PR statement, not even close to a technical requirement.  It is impossible to technically evaluate any proposal on this basis.

What exactly are the requirements and use cases of the EME API?

* Let set A be all the capabilities of a web browser with EME API.

* Let set B be all the capabilities that this proposal enables, a separate web browser and limited DRM media player.

What is the difference?

* It is certainly not the capability to view DRM protected big-budget movies. Both proposals support this.

* It is certainly not the 'many and varied benefits of web technology' because both proposal support this.  This proposal just separates the DRM device or app from the web browser - the user still has a web browser to benefit from the 'many and varied benefits of web technology'.  Many of us dispute that DRM is compatible with web technology.

Please, please, tell us what are the requirements and use cases for the EME API?

Then let me amend the proposal to narrow this set even further.

 - it surely is not for viewing big budget movies.  We can look at the differences between this proposal and the EME to take a guess, but it hardly seems to be justified or to benefit the user.


So what are the requirements that justify continuing to advance the EME?

When I have a better understanding of your proposal, we can evaluate the differences.
It seems well enough defined to evaluate the differences.  You have asked how much of the web browser can be included in the media player and the answer is 'as little as possible' and 'it is not a web browser'.  Do you have any other questions?

cheers
Fred