Re: Encrypting content stored on untrusted CDNs

On Wed, 29 Feb 2012, Kornel LesiÅ~Dski wrote:
> On Tue, 28 Feb 2012 23:09:58 -0000, Ian Hickson <ian@hixie.ch> wrote:
> >
> >   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.
> 
> How about defining a new scheme which includes the key in the URL?
> 
> Example modeled on "password" part of HTTP URLs:
> 
>    myVideo.src = 'http+aes://' + escape(mykey) + ':@cdn.example.net/video123';
> 
> Although not so pretty, it would readily work in all places where URLs 
> do, including HTML markup.

I can't see any problem with this off the top of my head. It neatly solves 
the problem for every content type, not just HTML, which is great for 
dealing with the manifest cases Mark mentioned.

Would we want to also support this over https? I suppose it's possible 
that we'd have a situation where we trusted a CDN to know the URL that a 
user was requesting but still wanted to protect the user from his network 
peers knowing what URL he was getting...

Anyone want to write a spec for this?


On Wed, 29 Feb 2012, Mark Watson wrote:
> On Feb 28, 2012, at 4:31 PM, Ian Hickson wrote:
> >>
> >> There are container format-specific specifications for this, for 
> >> example the Common Encryption specification for the ISO file format 
> >> (mp4).
> > 
> > What does this provide that's better than just whole-file encryption?
> 
> All of the index, framing and timing information is in the clear.

That seems like a net negative. The use case here is protecting private 
content from potentially hostile hosting intermediaries. I don't see why 
we'd want to let them see framing and timing information, the list of 
tracks, and other such information.


> Only the media samples themselves are encrypted. This means a great deal 
> of client logic: streaming, buffering etc. can be done before 
> decryption, supporting an architecture where decryption, decoding and 
> rendering are provided by the device or separate software module.

AES streaming encryption can be done trivially, there's no need to 
special-case the media case here, IMHO. There's especially no particular 
reason why decoding and decryption should happen together.


> Another advantage is that a number of different content protection 
> systems support this encryption format (or soon will).

I don't see how that is relevant.


> >> There may be more than one key associated with a given resource.
> > 
> > Can you elaborate on that?
> 
> This is feature of the file format. Some people imagine using that for 
> key rotation. I guess a single file could have been assembled from 
> multiple components with different keys (by a tool which did not have 
> the keys).
> 
> In the case of adaptive streaming, the different resources may have 
> different keys.
> 
> If the above sounds incomplete/weak that's just because I don't myself 
> have a strong use-case for multiple keys for one file - but it's a 
> feature of the Common Encryption format.

We don't need an encryption format to handle this use case. It's more 
simply handled for all media types by simply passing the entire stream 
through AES-CTR.


> > It's when you're trying to prevent the user from getting to the 
> > content that it stops making any kind of sense.
> 
> Yes, I understand this does not make any sense to you. But it does to 
> others. It's a pre-requisite for services like Netflix to use HTML5 
> instead of plugins.

Having a plugin system for DRM would mean you were not doing something 
"instead of plugins". It would just be doing it with different plugins.

There is no value to the user for you to use HTML rather than Flash if 
you're still going to require a proprietary plugin. The value of an open 
standard is that anyone can write an interoperable user agent without 
needing to coordinate with anyone else, and get full access to all the 
content on the Web. DRM completely undermines this. It compromises the 
very purpose of having a standard.


> This list is not the place to argue the ethics of that.

It _absolutely_ is. If you want this group to do something, then this 
group's list is the _only_ relevant place to discuss whether it is ethical 
or not.


> W3C needs to decide whether to work on making that a possibility, or 
> whether HTML5 is simply not going to be a suitable technology for our 
> segment of the industry, which would be a shame.

No, Mark. The shame is that people's rights are being taken away by 
paranoid content producers who don't trust their users, and that there are 
any software engineers willing to do this for them. And shame is 
absolutely the right word for this.

It is morally wrong to deprive users the ability to time-shift or 
format-shift content they have paid for.

It is morally wrong to deprive users the ability to reuse content they 
have paid for purposes of parody.

It is morally wrong to deprive users the ability to criticise content 
they have paid for.

DRM doesn't stop copyright violations, and is unnecessary for the purposes 
of selling media (indeed it seems to actually reduce total sales). The 
music industry figured this out a few years ago. Your industry will figure 
it out eventually too.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'