Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

On Mar 2, 2012, at 1:36 AM, Henri Sivonen wrote:

> On Thu, Mar 1, 2012 at 9:33 PM, Mark Watson <watsonm@netflix.com> wrote:
>> Below is a review of the proposal you posted yesterday.
> 
> Thank you.
> 
>> If the keys are available to the browser code, then this probably wouldn't
>> work for most of our content, since a browser could be trivially modified to
>> release the keys.
> 
> The keys would be exposed to browser code in the straw feature I
> described, yes. Note that if the CDM exposes clear pixel and audio
> sample data to the browser, the browser could be modified to dump the
> pixel and audio sample data in which case releasing the keys would be
> moot.

Actually, no, releasing the keys and releasing the decoded frames are not considered equivalent. I believe because redistribution of the decoded material is a substantially different task from redistribution of the keys + encrypted content URLs.

> 
>> another issue is that you (presumably) rely on
>> standard HTTP authentication to authenticate the user.
> 
> HTTP-only cookies over HTTPS could be used. It's very secure if the
> browser hasn't been modified and the straw feature I outlined didn't
> attempt to deal with browsers instrumented specifically to defeat the
> feature, since instrumented browsers could dump content in the case
> where a CDM provides clear pixels and audio samples to the browser
> anyway.
> 
> The key loading HTTP request could include a Sec-Foo header that can't
> be faked with XHR.
> 
>> Performing the decryption at the HTTP layer has the following problems:
>> - HTTP servers have to support the additional headers, which means CDN
>> changes are necessary. Even trivial CDN changes take time to roll out across
>> the world and CDNs generally want some compensation. Anything which
>> restricts our choice of CDNs increases our costs and reduces user quality of
>> experience (due to reduced diversity). So there's value to us if the
>> solution works with existing HTTP services.
> 
> So adding a couple of static-per-file HTTP headers to CDN content is
> too onerous for you, but you consider it reasonable to ask browsers to
> deal with all the complications of supporting CDMs. Wow.

I'm at a loss to understand how this is a response to my comment on your proposal. Obviously, if simply adding static per-file HTTP headers would enable us to deliver our service to HTML5 players I would be delighted. 

I'm not asking browsers to do anything. I'm explaining what technical capabilities are required to support services like ours and making a proposal for how to expose those capabilities in HTML. Noone has to support these capabilities who does not want to. 

...Mark

> 
> -- 
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>

Received on Friday, 2 March 2012 23:36:27 UTC