W3C home > Mailing lists > Public > public-html@w3.org > February 2012

Re: Encrypting content stored on untrusted CDNs

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 28 Feb 2012 15:22:48 -0800
Message-ID: <4F4D61C8.4000907@jumis.com>
To: Ian Hickson <ian@hixie.ch>
CC: Mark Watson <watsonm@netflix.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Kornel LesiƄski <kornel@geekhood.net>, "<public-html@w3.org>" <public-html@w3.org>
On 2/28/12 3:09 PM, Ian Hickson wrote:
> On Tue, 28 Feb 2012, Mark Watson wrote:
>> The server is not necessarily trusted. As I said, https services from
>> CDNs (where they also sell you trustworthiness) are more expensive than
>> http ones.
>>
>> So I want the content encrypted in storage as well as transport.
> This particular use case makes a lot of sense, and seems much more broadly
> applicable than just media. For example, you could have a CDN store
> private user information in the form of a JSON blob but want it encrypted
> on the CDN. Or you could have the user's private image library stored on a
> CDN, and want only the user to be able to see the content.
>
> One way to solve this would be to provide a method that takes an
> ArrayBuffer key and a URL, and have any subsequent fetch of that URL for
> the browsing context be decrypted automatically using that key:
>
>     navigator.addKeyForURL('http://cdn.example.net/video123', mykey);
>     myVideo.src = 'http://cdn.example.net/video123';
>     myVideo.autoplay = true;
>
> The scoping for such a feature would be hard to specify though.
>
> Another way would be to do something similar to what Blob does, namely
> create an object that returns a new URL representing the decoded resource,
> as follows:
>
>     var data = new DecodedURL('http://cdn.example.net/video123', mykey);
>     myVideo.src = URL.createObjectURL(data);
>     myVideo.autoplay = true;
>
> (We can't use Blob itself because this has to be done cross-origin.)
>
> Data would be encoded using AES256. I guess we could actually allow
> AES128, 192, and 256 by just allowing the key argument to be either 16,
> 24, or 32 bytes long.
>
Again, hook this through XHR or improve and/or generalize the mechanism. 
The "DecodedURL" kind of does that.

Why is AES the baseline?

If it's going to be pushed through an ArrayBuffer, it may be processed 
through a web worker, as a stream. And again, there's a lot of good use 
cases for streaming data through a worker. We've got the array buffer 
chunked response type in discussion, we've got Transferable working 
these days.

We don't have a great means for adding streaming data to an object url, 
though that's certainly in discussion with various proposals. And as 
I've said, it's implemented in Chrome.

-Charles
Received on Tuesday, 28 February 2012 23:23:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:30 UTC