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

On Wed, Feb 29, 2012 at 11:14 PM, Mark Watson <watsonm@netflix.com> wrote:
>
> On Feb 29, 2012, at 12:27 AM, Henri Sivonen wrote:
>
>> On Tue, Feb 28, 2012 at 12:35 AM, Mark Watson <watsonm@netflix.com> wrote:
>>> These are obviously fairly general statements - the proposal doesn't prescribe a model for where CDMs will come from and we appreciate opinions and ideas on that topic.
>>
>> Without knowing the nature of the CDMs, the impact of the proposal
>> can't be evaluated. It can't even be evaluated if the proposal
>> proposes a sensible API without having a good idea of what kind of
>> things CDMs would be.
>
> What level of information would you like to see?

What does the CDM do? Who has the permission to write, ship and
execute code that does what the CDM is required to do? How are these
permissions given to others? Are there parts of the implementation
(i.e. stuff that isn't downloaded from the site as part of content;
e.g. keys that don't arrive from the site) that are secret (i.e.
cannot be put in a public source code repository)? If there's a secret
component, who decides who gets to know that secret and incorporate it
in products? Under what terms?

Or more concretely, if someone is shipping a device with a new CPU
instruction set (and the CPU isn't powerful enough to emulate another
CPU to run a binary blob made for another CPU) and new kinds of OS
APIs underneath a browser on that device, what steps are necessary to
ship a CDM compatible with Netflix content on that device and have the
browser use it so that it can view Netflix content?

> I assume you're interested in more about the functional split between CDM and browser, right ? If a detailed example API for a browser communicating with a CDM were provided, would this be sufficient ?

I think the premise that the CDM is separate from the browser is
troubling, but since that seems to be a substantial part of the
proposal, understanding the interface between a browser and a CDM
would be important. However, it's not sufficient. Understanding who
manages the permissions to make compatible implementations of CDMs,
ship CDMs and integrate with CDMs, how and under what terms is much
more important.

(Generally with W3C specs, there are no deliberately secret parts and
an implementor doesn't need to ask for permission, since the specs are
royalty-free to implement.)

>> But let's take a step back from CDMs and try to understand the
>> motivating requirements better.
>>
>> So far, the requirements from the content provider point of view that
>> I've seen are:
>> * Decrypted data must not be available to JavaScript
>> * Speedbump to deter users from saving decrypted content
>
> The speedbump was an analogy to illustrate that something doesn't have to be perfect to be useful. The requirement for content protection is that it really is genuinely difficult (in ways that can be measured in terms of the expertise, equipment and time required) to obtain the keys or decrypted content.

(Reordered quotes to hoist example 2 here.)
> Example 2 (at the other end of the scale): A content protection system vendor provides a (closed-source, obfuscated) software component for multiple platforms that implements decryption and decoding of audio/video media. They adapt that component to support the CDM APIs offered by various desktop browsers. An OS vendor, browser maker or commercial video service arranges for that component to be installed on the users machine. Technically, the same component can be used by any service that supports the protection system in question and whose A/V codecs are supported by the CDM. The CDM returns decoded audio/video samples to the browser, which is implemented such that data returned from CDMs is not available to Javascript (e.g. through Canvas).

In your example 2, the CDM is separate from the browser and to obtain
decrypted content, the attacker needs to pull the source code of an
open-source browser, instrument it to dump decrypted frames and audio
samples, compile and run the instrumented browser.

A solution of the nature I outlined, which doesn't involve third-party
binaries or secrets in the browser implementation, could also be
attacked like this. Therefore, it seems to me that your example 2
below isn't substantially more robust against attacks by a skilled end
user of a media-providing site than what I outlined. However, your
example 2 would do harm to competition between different operating
system and devices while a solution of the nature I outlined would
not. Therefore, the sort of solution I outlined seems superior.

>> * Hiding content from untrusted CDNs that host the content
>> * Hiding content from eavesdroppers when the content is served over
>> HTTP without SSL/TLS
>>
>> (I also saw that there are unbounded requirements that can't be
>> enumerated for all content providers in general, but I hope it's
>> possible to gain a better understanding of the requirements of Netflix
>> in particular later on. After all, there must be some process that
>> lead to Netflix deciding to use whatever DRM Netflix now uses in
>> various cases.)
>
> Yes, the process is that we work closely with our content providers to determine what's acceptable to them in any given scenario. It's a two-way cooperative process that ultimately ends in a risk assessment and judgement call for any given platform, type of content etc. The judgement call is based on more than just the properties of the proposed content protection, but also includes engineering constraints and timescales, platform volume and other business aspects. Our content provider partners understand that their product is more valuable to us if we can deliver it to more platforms and we understand that they do not want our product to be easily usable for piracy.

I realize you don't get to make your content providers think more
clearly, but it's kind of pointless to focus on making your product
really hard to pirate content from when pirates only need to obtain a
copy of each movie *once* from *somewhere* (at the resolution they are
interested in or higher). If they have a generic crack for Blu-Ray,
what does it matter how difficult it is to obtain unscrambled content
from your service as long as it's more complicated than that searching
for a pirated copy elsewhere on the Internet? If a movie isn't
available on Blu-Ray, if one of your users manages to obtain it in the
clear from your service and share it, what does it matter how
difficult it is for the next person to obtain it from your service
(and there will always be at least one user who can get it extracted
from your service)?

It's rather sad to do harm to browser competition in order to develop
placebo for movie execs. :-(

> The point is that we are not proposing W3C to design a content protection system based on a specific set of content protection requirements. Others have designed such systems. Our proposal is about integrating those solutions with HTML.

The outcome I'm seeking is that all the functionality that browsers
expose to Web sites can be implemented by following public
royalty-free specs without having to ask permission from any entity
(e.g. CDM proprietor or a plug-in vendor).

>> From the browser point of view (well, open source browser at least),
>
> When you say 'open source' do you mean GPLv3 specifically, or open source in the broader sense ?

GPLv3-compatibility is a useful shorthand. If a solution couldn't be
implemented under GPLv3, chances are it is encumbered in ways that are
harmful to competition when it comes to launching new browsers or new
Web-capable devices.

>> some obvious requirements are:
>> * The system is fully specified and doesn't involve any
>> implementation-side secrets
>> * The system can be implemented by anyone and in Open Source software
>> * The system doesn't require browsers to interface with 3rd-party
>> black boxes that the browser vendors don't control (i.e. it should be
>> possible to have a fully-functional fully open source implementation
>> of the interoperable Web platform including all the supporting
>> software in the style of B2G and Chromium OS.)
>
> Why do you think these requirements apply to our proposal when they do not apply today in respect of plugins ?

Plug-ins are a problem. HTML <video> is supposed to solve that problem
for video. (Fast JavaScript, Web Sockets, WebGL, WebRTC, etc. are in
the process of solving the problem in other areas.) If your proposal
re-introduces an equivalent or worse problem, it's not an improvement
but a regression back to the bad state (or to a worse state).

As Boris pointed out, the problem introduced by CDMs may be legally
worse than the problems with plug-ins even when they seem technically
equivalent problems.

>> Here's a description of a straw feature that I believe meets all the
>> above requirements. Would this system be adequate for Netflix to serve
>> movies to a browser that implements this feature? If not, why not
>> specifically? (The main purpose of this exercise is to gain better
>> understanding of the requirements. This isn't an offer to implement
>> this straw feature.)
>
> I will review the proposal in detail and get back to you. As explained above, the answer to your first question is not a simple binary one, and not one that Netflix could answer alone.

Thank you.

> Would you be willing to conduct a similar review of our proposal ?

I reviewed it and concluded that it leaves substantial parts
undefined, so its impact cannot be assessed from the proposal.

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

Received on Thursday, 1 March 2012 09:00:14 UTC