W3C home > Mailing lists > Public > www-archive@w3.org > February 2013

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

From: Henri Sivonen <hsivonen@iki.fi>
Date: Sun, 3 Feb 2013 17:09:20 +0200
Message-ID: <CAJQvAuePAUoZoXPDjc+D7YufC-W75LO_ORxLG5otZhj9q987XQ@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: Maciej Stachowiak <mjs@apple.com>, www-archive <www-archive@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>, Sam Ruby <rubys@intertwingly.net>
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.

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.

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.
Received on Sunday, 3 February 2013 15:09:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 3 February 2013 15:09:49 GMT