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

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

From: Henri Sivonen <hsivonen@iki.fi>
Date: Fri, 2 Mar 2012 11:22:47 +0200
Message-ID: <CAJQvAucYkQUdzWQ9NrtWpJwmq7YbF20e7XYX6DHgzU9opKDt+w@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: "<public-html@w3.org>" <public-html@w3.org>
On Thu, Mar 1, 2012 at 8:06 PM, Mark Watson <watsonm@netflix.com> wrote:
> - what we propose to standardize is the discovery, selection and interaction
> with CDMs, not the CDMs themselves (not unlike the current situation with
> codecs).

I understand that, but I think that's fundamental problem with the
proposal, because to achieve interoperability, the functionality
exposed to Web sites needs to be known and replicable.

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

Typically a W3C spec doesn't limit how you implement stuff that is
exposed to Web content but specifies the functionality exposed to Web
content. Your proposal leaves a significant chunk of functionality
exposed to Web content unspecified.

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

That's a significant problem.

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

The codec situation isn't truly open-ended in practice. In practice,
there are three formats: Theora/Vorbis/Ogg, VP8/Vorbis/WebM and
H.264/AAC/MP4. How these formats are decoded is not a secret. IANAL,
but decoding these formats doesn't risk invoking anti-circumvention
laws. The encumberance is that one set of implementors isn't OK with
the patent licensing regime of H.264/AAC/MP4 and another set of
implementors says it doesn't trust the patent licensing regime of
VP8/Vorbis/WebM or Theora/Vorbis/Ogg.

CDMs are qualitatively different from codecs, because:
 1) So far, the list of CDMs isn't down to a very small known number
(3 in the case of codecs at the moment, though H.265 or Daala could
increase the number)
 2) In addition to being encumbered by patents, CDMs could be
encumbered by trade secrets. (If there aren't secret algorithms, there
might be secrets keys that an implementation needs to incorporate in
order to be compatible.)
 3) In addition to being encumbered by patents, it seems (IANAL,
though) that being compatible with a CDM without permission might run
afoul with anti-circumvention laws.

As for plug-ins, there's one that's still a big deal: Flash Player. If
a new platform doesn't support Flash, people notice. If a new platform
doesn't support Java or Silverlight or whatever long-tail plug-in,
that's pretty much OK as far as market acceptance goes. Plug-ins other
than Flash matter for competitiveness only relative to other browsers
on an OS that already has other browsers that support Java,
Silverlight, etc.

In the case of launching a new OS, plug-ins are different from CDMs, because:
 1) There is only one plug-in (Flash Player) to deal with
 2) It's possible to code your way around most .swf content on the
Web: You can write an independent implementation of .swf player that
deals with restaurant menus. If you license the codec patents, you can
support video, too. Full compatibility by coding around the problem
stops at the CDM inside Flash Player, so at the limit, the situation
reduces to one CDM. (Though even one CDM that your product isn't
compatible with might be one too many.)

So yeah, for new OSs, the CDM situation might be similar to the Flash
situation in practice.

In the case of launching a new browser for an existing OS that already
has NPAPI Flash Player, the situation is different from CDMs, because
you can implement an NPAPI host royalty-free, without asking
permission and without making an bizdev deals. (You get Silverlight
and Java as a bonus with some more bug workarounds.)

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

By *the* CDM I meant one that Netflix targets. (Implementing *a* CDM
that Netflix doesn't target isn't particularly interesting scenario.)
If no permission is needed, surely the CDM can be described fully in a
royalty-free W3C spec.

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

That seems like a severe barrier for making competing hardware that
can play the same content. Such a barrier seems antithetical to the
purpose of W3C specs.

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

"Secure" enough to view movies from Netflix.

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

That seems like a huge barrier considering that currently,
implementing the interoperable Web platform doesn't involve *having
to* work with any other vendor.

> In Netflix's case we also have a security specification they need to meet.

Is that specification public?

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

Well, you are making the choice of targeting non-Royalty-Free technology.

Why should the Web at large and the W3C specifically grant you an
exception and let you introduce non-Royalty-Free parts to the
platform?

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

The point of W3C specs being Royalty-Free isn't that the W3C only does
royalty-free stuff. The point is keeping the Web royalty-free. Leaving
a non-Royalty-Free part out of W3C specs but still de facto making it
part of the functionality browser expose to Web content completely
misses the point of why W3C specs are Royalty-Free.

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

Competition in many markets depends on products being substitutable to
a useful degree. In the case of Web browsers, the useful degree of
substitutability is that the would-be competing browser can render the
Web. If rendering the Web involves access to a CDM that a would-be
competing browser cannot access or replicate, the would-be competing
browser can't render the Web and isn't a useful enough substitute for
incumbent browsers.

> Authors have a right to license their works in any legal manner they choose
> (this applies to software authors as well as movie authors).

I don't think the Web platform should movie allow authors to enforce
their manner of licensing in a way that's harmful to software authors.

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

I don't see why a technical group couldn't elect not to support
something that someone says they require. In particular, when two
parties state mutually exclusive requirements, both cannot be
satisfied and being judgmental about what requirements don't get
satisfied is a logical necessity.

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

I mean a scenario like this:

A vendor wants to launch a new class of Web-capable device. To be
accepted by users (i.e. to have a chance to succeed in the market),
the new device needs to support existing Web content. Some existing
Web content depends on a CDM to work. The CDM contains secrets and
those secrets are managed by a cabal. The cabal refuses to give
permission to the vendor to incorporate the secrets in the new class
of Web-capable device (either refuses outright or imposes onerous
conditions). The vendor reverse engineers the CDM and implements a
software component that performs the same function as the CDM.

How does this not run afoul with the DMCA or similar laws?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Friday, 2 March 2012 09:23:19 GMT

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