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.

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

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:48 UTC