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 11:35 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Tue, Feb 28, 2012 at 9:07 AM, Glenn Adams <glenn@skynav.com> wrote:
> > 2012/2/28 Tab Atkins Jr. <jackalmage@gmail.com>
> >> 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

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