- From: Glenn Adams <glenn@skynav.com>
- Date: Tue, 28 Feb 2012 11:45:10 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Mark Watson <watsonm@netflix.com>, Kornel LesiĆski <kornel@geekhood.net>, "<public-html@w3.org>" <public-html@w3.org>
- Message-ID: <CACQ=j+cVrwdD4MofTpgtM6EMq9GpsH+QxPhBmWFhma0QwNGrog@mail.gmail.com>
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
Received on Tuesday, 28 February 2012 18:45:58 UTC