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

Henri,

Reading your mail I have a feeling we are talking a little at crossed purposes. Part of this could be because the proposal is not yet clear enough on the nature of CDMs and these discussions are very helpful in eeking out the issues which need to be explained/addressed.

To clarify:
- a browser can have multiple CDMs for different keysystems
- what we propose to standardize is the discovery, selection and interaction with CDMs, not the CDMs themselves (not unlike the current situation with codecs).

The proposal doesn't restrict how browsers integrate with CDMs, how they are installed, discovered by browsers etc. This is up to browser developers and there are many options. Most of your questions are about commercial choices by browser developers and CDM developers.

Do you think the proposal should or could place restrictions on these choices ? What restrictions and how could we do that in a technical specification ?

Obviously, the solution is not as good as a single royalty-free standard for content protection acceptable to everyone. Unfortunately I don't believe such a thing exists (any more than a single royalty-free video codec acceptable to everyone, in fact even less).

I don't see the proposal as qualitatively different from the current situation with plugins or codecs. One way to look at it is the following: Today, browsers need to support plugins to provide functionality they don't want to support natively. Now that most of the functionality in plugins *is* natively supported in browsers, we're trying to pull out the remainder into a different, simpler, concept with the object that this provides more commercial options for all browsers.

Please see inline also...

...Mark

On Mar 1, 2012, at 12:59 AM, Henri Sivonen wrote:

On Wed, Feb 29, 2012 at 11:14 PM, Mark Watson <watsonm@netflix.com<mailto: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<mailto: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?

The CDM implements the client side of a content key deliver mechanism, decryption of audio/video samples and, possibly, decoding and, possible, rendering of the result.

Who has the permission to write, ship and
execute code that does what the CDM is required to do?

I don't see why anyone would need permission from anyone else.

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)?

Some CDMs will rely on secret keys to secure the content key delivery. How the keys are delivered is up to the CDM. For example, if a CDM is shipped with a device, like a TV, the keys are often burned into the hardware during manufacture.

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?

That would depend how secure you want the device to be.

For example, if the device was a TV, say, and the manufacturer wished it to have access to content with the highest protection requirements, they would need to work with a CDM vendor (or use something like Marlin), port the CDM to their new CPU and plumb it in to whatever API their chosen browser expects CDMs to have. They would also need to meet the robustness requirements that come with their chosen protection system. In Netflix's case we also have a security specification they need to meet. This would be substantially easier than what they need to do today to support Netflix.


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,

Maybe, but we don't have much choice about that because some protection systems use non-Royalty-Free technology.

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.

Ok, but those are all commercial, not technical issues. If there's anything we can do from the specification side on those topics, I'd love to know.


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

Yep. Not proposing to change that. In fact this is exactly why CDMs might be separate from the browser.


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.

Possibly, for this specific example (I haven't reviewed your proposal yet). But as I said, this is just one example at one end of the scale.


* 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

You are addressing these arguments to the wrong person and on the wrong list.

(and there will always be at least one user who can get it extracted
from your service)?

There is not always one who does. As far as I know the content protection we employ is working very well.


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

I am not clear how the proposal would do harm to browser competition.

Authors have a right to license their works in any legal manner they choose (this applies to software authors as well as movie authors). You clearly believe that some of these choices are misguided/pointless and you don't want to do technical work to support distribution of those works. That's fine. But others feel differently and would like to make these works available to customers. And as has been empirically demonstrated, customers, in their millions, would like convenient ways to enjoy these works on the Internet under the terms the authors are offering.


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.

What I understand is that GPLv3 explicitly prohibits use of technologies that many content authors license terms explicitly require (This is not true of "Open Source" licenses more generally).

Again, both licensing choices are valid, the respective authors are completely within their rights to make those choices and I don't believe as a technical working group we are entitled to be judgmental about that.


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

I believe the situation will CDMs will be no worse than plugins and likely much better (see the discussion with Boris for why).

The point is that <video> has not solved the problem of plugins, because <video> cannot be used with most professional content. To say that content authors should change their licensing/business approach is not a solution any more than saying that Open Source software authors should change their license terms to include patent-encumbered technologies.

CDMs may also be less like plugins and more like codecs. Codecs are also a problem (which CDMs can actually help with since they may also include decoding functionality).

Providing more technical ways for browsers (including open source ones) to enhance the capabilities of <video> with those needed to play the content out there is surely an improvement.


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.

If you mean the question about whether the browser side of the CDM API can be implemented in a DMCA-safe way, this is something we have to solve in the proposal, and I'm confident we can.


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<mailto:hsivonen@iki.fi>
http://hsivonen.iki.fi/