Re: CfC: to publish Encrypted Media Extensions specification as a First Public Working Draft (FPWD)

On Sun, Feb 3, 2013 at 8:09 AM, Henri Sivonen <hsivonen@iki.fi> wrote:

>  On Feb 3, 2013 3:24 PM, "Glenn Adams" <glenn@skynav.com> wrote:
> > For example, an alternative proposal might be to reframe EME as an
> extension to TLS that would allow a pluggable key and encryption method in
> TLS as well as a JS API that interacts with TLS that serves the same
> functions as being proposed with EME.
>
> EME tries to address cases where the browser engine is not trusted with
> the decrypted but still compressed H.264 bitstream. Supporting that "same
> function" while pushing stuff to TSL would make the integration point
> between the user-replaceable part of the browser codebase and the Hollywood
> domain even trickier than with EME.
>
Agreed. I just wished to point out that an alternative approach is
possible, not preferred. Further, I wanted to point out that TLS is
actually extensible, both in encryption and key algorithms, so, in some
ways, what EME is asking for is already present in essence, though not the
key management APIs.


> So I think pushing things to TLS just to pretend to use an existing
> extension point would be an improvement as long as the assumption is that
> the browser engine won't be trusted with the decrypted codec bitstream in
> some Hollywood content scenarios.
>
Actually, I think EME would be better than attempting to integrate a set of
JS APIs with TLS.

> If you have information that says the decrypted codec bitstream can be
> given to user-replaceable browser engines (the way TLS normally terminates)
> in all relevant scenarios, it would be helpful to bring that information
> forward.
>
I don't. If and when I should have such information, I'll definitely
attempt to make it public. However, I think it to early in the EME
lifecycle to have such decisions/commitments from content providers/owners.
Things tend to move relatively slowly in terms of actual usage and
deployment policy. EME will have to be deployed on UA platforms, CDMs that
support the desired systems will need to be integrated or made available as
UA add-ons, and content providers will need to deploy and verify their
current content based on legacy encryption/key systems before content
owners will move to new policies.

However, if some of the newer systems, say DECE/UV, were to become
available via EME, then I would expect a definite push from both content
providers and owners to transition to that framework, including potential
changes to policies based on legacy implementations.