W3C home > Mailing lists > Public > public-html@w3.org > February 2012

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 28 Feb 2012 10:48:08 -0800
Message-ID: <CAAWBYDCfXa4hQZV8TR9TJmCiaC-R2uc8CC8+T2OBJh6yv66Fuw@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: Mark Watson <watsonm@netflix.com>, Kornel Lesiński <kornel@geekhood.net>, "<public-html@w3.org>" <public-html@w3.org>
On Tue, Feb 28, 2012 at 10:45 AM, Glenn Adams <glenn@skynav.com> wrote:
> 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

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

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:48 UTC