- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 28 Feb 2012 10:48:08 -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 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. ~TJ
Received on Tuesday, 28 February 2012 18:49:00 UTC