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

Hi Henri,

I think we are getting closer to clarifying the points on which we disagree. This discussion has been very useful for me, so thank you. I hope you have found it useful too. I've included a few further comments below.

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

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

Interoperability between what and what exactly ?

The intention of the proposal is to define the functionality that is exposed as far as possible. It's certainly better defined than other proposals for content protection in HTML such as that of the OIPF (as adopted in HbbTV and elsewhere).

The functionality of the CDM, and the semantics of the messages it passes, are defined by the specification. Exactly how it codes data into those messages to achieve the results defined in the specification is left to the CDM.

As seen by a client side Javascript player, all CDMs work the same way. Application servers can also be developed in a way that is independent of the protection system. All that is protection-system specific is the content of the messages passed from CDM on the client to a back-end license server and back. I don't see any way to avoid that being protection-system specific.

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

Again, it's not dissimilar from codecs. What a codec does is well-defined (converts encoded video to decoded pixels) but the exact format of the input data is codec-specific. For a CDM, the form of the input (media) data is container-specific and for form of the message data to/from the CDM is CDM-specific. You don't need to do anything with this message data except treat it an an opaque blob and transport it to the license server.

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

If we assume for a moment that a 'single royalty-free standard for content protection acceptable to everyone' does not exist, what do you suggest we do ? 

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

I think there are other reasons too, but that's a side issue.

I don't expect there to be a vast number of CDMs. Probably there will be a handful, just like the codec case. I think this because I doubt browsers will want to enable or encourage users to install arbitrary numbers of CDMs.

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

That's a quantitative difference ;-) But see above.

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

True.

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

IMO, we need to make sure that it is possible to implement the browser side of the CDM API without such problems.

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

I thought you meant *a* CDM - my mis-understanding of the question. Anyone can implement a CDM and come ask us if it meets our requirements.

If you mean who has permission to write and ship implementations of Widevine, for example, you'd better ask Google. If I had to guess I'd say Google and their licensees. 

We use other content protection systems too. Probably the answer is similar.

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

We work with many TV manufacturers and this is done on 100s of different devices. It's not an especially big deal.

> Such a barrier seems antithetical to the
> purpose of W3C specs.

We're not proposing to embed such requirements in any W3C specification.

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

You don't need to put secure in quotes: we all know it is a real-valued not binary-valued property.

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

Again, we do it on 100s of devices today and it's certainly not a hugh barrier.

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

No. It's available to any Netflix device partner, though.

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

No, that is not my choice. That is the choice of the licensees of the content we deliver. Again, they're perfectly entitled to make that choice.

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

They shouldn't. We're not proposing that.

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

I'm not sure I agree with that. What about H.264 ? This is part of the functionality several browsers expose to web content.

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

I don't understand how a would-be competing browser would not be able to integrate with a suitable CDM, unless it was by their own choice.

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

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

I don't think we can or should take a position on either of these statements. Both software and movie authors are entitled to choose their manner of licensing. Neither is in a position to 'enforce' it in a way that harms the other, since neither can 'force' the other to change their terms.

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

On technical grounds, sure.

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

The requirements are not mutually exclusive from a specification point of view.

Sure, GPLv3 authors choose not to implement the protection mechanisms that content owners choose to require. I don't take issue with either choice, but it does mean an entirely GPLv3 software stack cannot play this content (it's mostly H.264 anyway). That is the consequence of the respective authors choices. That's just how it is. No judgement.

I don't see why this stops us standardizing how those who do wish to write software for this content should expose those capabilities to HTML. Nor does it stop the resulting specification being implemented in GPLv3 code.

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

Well, you are supposing that there is only one type of CDM. Indeed, if a cabal had a monopoly on content protection mechanisms that would already be a problem for the industry generally - as monopolies always are.

We solve this by creating a market in CDMs - making sure that services can easily support multiple CDMs, that they are substitutable as you say above.  This is achieved by standardizing their functions and the mechanisms to interact with them ... exactly as we propose.

...Mark

> 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 Saturday, 3 March 2012 02:19:36 UTC