Re: Open Source implementations Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

On Tue, Feb 28, 2012 at 10:45 AM, Glenn Adams <> wrote:
> On Tue, Feb 28, 2012 at 11:35 AM, Tab Atkins Jr. <>
> wrote:
>> On Tue, Feb 28, 2012 at 9:07 AM, Glenn Adams <> wrote:
>> > 2012/2/28 Tab Atkins Jr. <>
>> >> In your other case (server is untrusted), DRM is unnecessary baggage;
>> >> you only need JS encryption/decryption that can be inserted between
>> >> the server and a <video> element of the user.  This can be specified
>> >> and implemented without many of the concerns that people have been
>> >> raising about this proposal.
>> >
>> > A solution that requires decryption of the actual media content in JS
>> > would
>> > be unacceptable from a performance perspective, particularly on resource
>> > constrained devices. The solution must be readily implemented with
>> > reasonable performance on devices at different ends of the spectrum,
>> > including TV/STBs (resource constrained).
>> emscriptem has apparently broken the order-of-magnitude barrier in
>> C-like speeds, so performance is likely much less of an issue than you
>> believe.
>> However, "decryption in JS" doesn't necessarily mean "written in JS
>> code", any more than "random numbers in JS" does.  Handing authors an
>> encryption/decryption module written in C++ with a JS API satisfies
>> the use-case, and still avoids the difficulties people have with DRM.
> granted; perhaps the more important issue is whether content providers that
> wish to use this encryption proposal will accept the possible exposure of
> plaintext form of content to JS; it is one thing to expose it in the UA
> implementation, but another entirely to expose it to client side JS

I was specifically addressing the "user is trusted" case.

> regarding possible citations about performance on constrained devices, I am
> basing my input on a number of years of representing a consumer electronics
> manufacturer (Samsung) that builds both TVs and STBs; i do not have public
> documents to cite that verifies my claim, so you'll just have to accept my
> input (or not)... sorry

Unfortunately, years-old performance information is effectively
useless at this point, given both Moore's Law and the amazing progress
of projects like emscriptem.


Received on Tuesday, 28 February 2012 18:49:00 UTC