- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 28 Feb 2012 10:35:39 -0800
- 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 UTC