- From: Kornel Lesiński <kornel@geekhood.net>
- Date: Tue, 28 Feb 2012 21:38:39 -0000
- To: public-html@w3.org
On Tue, 28 Feb 2012 17:07:14 -0000, Glenn Adams <glenn@skynav.com> wrote: > A solution that requires decryption of the actual media content in JS > would be unacceptable from a performance perspective, particularly on > resource > constrained devices. I think performance issue can be avoided in two ways: 1. Use JavaScript only to generate key for stream encrypted using a standard cipher. Instead of decrypting many MB of the stream, JS would only need to decrypt 32 bytes holding the key. 2. Provide JavaScript with access to natively-implemented helper functions for typical tasks in cryptography (SIMD for XORs and shifts of arrays, operations on polynomials, standard hashes, etc.). JavaScript only acting as a "glue" between many native functions may have orders of magnitude lower overhead. Although to be honest I don't see the point of tying to do content protection in JS. Such well-specified interoperable environment will be ineffective for user-is-adversary use case. For secure transport we have HTTPS already. The remaining case — secure storage with untrusted parties — should rather have a simple, native solution. Special UI for giving browser decryption password in a way that makes it clear that password doesn't go to a remote site is important, and JS can't do that by design. -- regards, Kornel Lesiński
Received on Tuesday, 28 February 2012 21:39:05 UTC