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: [email protected]
To: [email protected]
CC: [email protected]; [email protected]

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 <[email protected]> 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 <[email protected]> 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.






                                          

Reply via email to