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

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.

> 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.

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

Received on Friday, 2 March 2012 09:37:19 UTC