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:35:39 -0800
Message-ID: <CAAWBYDC7i_tUvUmOsbSPET+nBRTOBbKZXyqM3+p3+WA5Z_D3=Q@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 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.

~TJ
Received on Tuesday, 28 February 2012 18:36:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:46 GMT