Re: Encrypted Media proposal: Summary of the discussion so far

On Mar 9, 2012, at 1:02 PM, Mark Watson <watsonm@netflix.com> wrote:

> 
> On Mar 9, 2012, at 10:09 AM, Charles Pritchard wrote:
> 
>> On Mar 9, 2012, at 9:44 AM, Mark Watson <watsonm@netflix.com> wrote:
>> 
>>> 
>>> On Mar 8, 2012, at 4:15 PM, Charles Pritchard wrote:
>>> 
>>>> In my imaginary life, I would write a CDMs baseline using websockets masking key, and add it to that specification as the default keysystem.
>>>> 
>>>> Vendors and authors have mature websockets masking code.
>>>> http://tools.ietf.org/html/rfc6455#section-5.3
>>>> http://dev.w3.org/html5/websockets/
>>>> 
>>>> Content would be masked on the network (CDN?) all the way through to the media element (CDMs) stream processing.
>>>> So the network sends the whole file websockets masked, it gets unmasked by the browser as the file is read.
>>>> This would typically look like a blob:*: uri to debugging tools when running a url inspector.
>>> 
>>> Charles - I'm not sure I understand the point of using WebSockets masking.
>>> 
>>> I just read that part of the spec, and masking appears intended to avoid data being inadvertently interpreted by intermediaries, since it was discovered that some intermediaries would interpret HTTP requests embedded in websockets frames and this could open the possibility of a cache poisoning attack.
>>> 
>>> In this case we do not have any such problem of accidental interpretation of media data. Masking doesn't hide the data from anyone deliberately trying to read it.
>>> 
>>> What am I missing ?
>> 
>> 
>> It fulfills the requirements that content vendors place on distribution by obfuscating the file stream.
> 
> Generally, the content owners would like the stream to be encrypted and the key to be distributed securely. So obfuscation doesn't meet that requirement.


The baseline CDM is not intended to serve content producers that want data encrypted through mp4 mechanisms.

No fully open source stack would be acceptable to your clients: they want to know the key has been thoroughly hidden from the end user.

This strawman is meant to address only two things: obfuscation and a CDM baseline. It does both. Obfuscation is sufficient for DRM provisions.



> 
>> A user can not simply download the file and then view it in a media player. It obfuscates the stream over wireless so apps like Firesheep can not simply snoop the video automatically.
> 
> With trivial modifications, they could.


Same applies to DVDs these days. Same used to apply to many Netflix streams. Same still applies to iTunes DRM unlocking. And Blu-ray.

Cracking streams is trivial; though in JS we can obfuscate things on a pet site basis, which is cool.

The point is not to be invulnerable, only to meet legally justifiable terms.



> 
>> 
>> It provides a baseline for server-client key passing and can be implemented practically and easily by open source vendors, which is what they seem to be looking for.
> 
> I feel I'm missing something, because above you talk about masking the stream, but here you're talking about key passing.


You mask the stream with a masking key; I'd imagine if the stream became unreadable, it'd fire off another key request; a stream could have several keys used throughout.


The masking key is delivered separately from the media stream.




> 
>> 
>> So, it fulfills legal and technical obligations. It's a baseline for the CDMs use case and section, it's a way for distributirs to qualify for DRM-DMCA enhanced protections while still sending data in an open source compatible stream.
> 
> What's the advantage over the clearkey keysystem proposed ?

I was not able to discern a system in place with clearkey. It looks like a raw pipe and an abstraction class which sends out errors if your use of the class is wrong.
> 


I don't believe clearkey is actually defined for use. It's just a template to get started. It's called an abstract object in many languages.

-Charles