Re: Proposal: Internet Encrypted Media Extensions

On Tue, Jan 28, 2014 at 9:54 PM, Fred Andrews <fredandw@live.com> wrote:

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

My understanding is that implementors of the Presentation API could expose
devices that did not support a full UA, but rather supported specific
applications and, knowing the specific URL forms that these applications
supported, could enable a web page to present content from those specific
URLs using the specific applications on those devices.

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 ?


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


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


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

...Mark



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