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: Kornel Lesiński <kornel@geekhood.net>
Date: Tue, 28 Feb 2012 21:38:39 -0000
To: public-html@w3.org
Message-ID: <op.waerqpevte2ec8@aimac.local>
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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:21 UTC