RE: Proposal: Internet Encrypted Media Extensions

The Wiki notes requirements that content should be playable in a reference media player application on an EME capable web browser, and also that content should be playable on a media player that does not implement a web browser or the EME API.  Combined this narrows the solution space in a concrete way.

The Presentation API appears to redirect to a web browser, whereas the proposal would specifically not redirect to a web browser but rather to a media player that does not give the web developer access to a general web browser.  The Presentation API might be capable of doing the redirection, but the target protected device would not expose a web browser rather just a media player.

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.

The EME proponents have still not disclosed their requirements - 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?

cheers
Fred

Date: Tue, 28 Jan 2014 09:05:02 -0800
Subject: Re: Proposal: Internet Encrypted Media Extensions
From: watsonm@netflix.com
To: singer@apple.com
CC: fredandw@live.com; public-restrictedmedia@w3.org

It's great to have a proposal, but I too can't quite work out what is proposed from the material on the Wiki. Could you make it more concrete ? Perhaps an example or outline of a solution that would meet the requirements as you have stated them ?

Specifically, when you say "Some users need the convenience of viewing protected content on their general purpose computer and are not too concerned about the security and privacy implications of their computer being controlled by publishers. Some users need security and privacy so need to view protected content on separate sand-boxed devices." it suggests to me something like the Presentation API [1] which, amongst other things, could allow a web page to control media playback taking place on another device, such as a TV.


If I understand correctly, you are looking for some kind of isolation between the web page / User Agent and the protected media player. I would like to better understand what properties that isolation has which make this idea acceptable to you.


...Mark

[1] http://webscreens.github.io/presentation-api/


On Mon, Jan 27, 2014 at 6:18 PM, David Singer <singer@apple.com> wrote:

I am fairly sure I don’t understand what you are proposing, alas.  Can you say more about what you’re proposing?  The Wiki talks about its advantages more than what it is.




The biggest clue I got was "by redirecting to a separate application”.  I don’t see how this is any advantage.  That application obeys DRM robustness requirements, just like something linked to EME.  The disadvantage is that it’s doing everything native — UI, the lot.






On Jan 26, 2014, at 18:32 , Fred Andrews <fredandw@live.com> wrote:



> An initial draft of a proposal to compete with the EME ABI and that is arguable better for the user, while still meeting the use case of users needing to view protect media content, and keeping DRM out of the web, has been published:


>

> http://wiki.whatwg.org/wiki/Internet_Encrypted_Media_Extensions

>

> Feedback and suggestions welcomed.

>

> cheers

> Fred



David Singer

Multimedia and Software Standards, Apple Inc.