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

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

From: Mark Watson <watsonm@netflix.com>
Date: Fri, 9 Mar 2012 19:02:52 +0000
To: Charles Pritchard <chuck@jumis.com>
CC: "<robert@ocallahan.org>" <robert@ocallahan.org>, Tab Atkins Jr. <jackalmage@gmail.com>, Glenn Adams <glenn@skynav.com>, Philip Jägenstedt <philipj@opera.com>, "<public-html@w3.org>" <public-html@w3.org>
Message-ID: <C7EF6527-4754-40B9-9D20-0D377854E84C@netflix.com>

On Mar 9, 2012, at 10:09 AM, Charles Pritchard wrote:

On Mar 9, 2012, at 9:44 AM, Mark Watson <watsonm@netflix.com<mailto: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.
<http://tools.ietf.org/html/rfc6455>
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.

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.


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.


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 ?


-Charles
Received on Friday, 9 March 2012 19:03:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:46 GMT