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

On Sat, Mar 3, 2012 at 4:19 AM, Mark Watson <watsonm@netflix.com> wrote:
> 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 ?

I meant "interoperability" in the W3C sense, which is short hand for:
Browsers A and B are interoperable for feature set F if Web content
developed to use feature set F in browser A implies that the Web
content works in the same way in browser B.

Substitutability might be a more correct word, since browser A and B
don't necessarily send any messages between themselves, but for better
or worse, "interoperability" seems to be the word that has stuck at
the W3C.

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

You said in another email that it's a requirement that mp4 files be
encrypted using ISO Common Encryption. That seems to mean AES-CTR
inside the container. So the message that ultimately needs to be
transferred is the AES-CTR key. It seems to me it would be possible to
define one message format for transferring the AES-CTR key to the CDM
and have the protection systems adapt to consume this one HTML media
key messaging format. I don't see why a priori HTML would need to
adapt to multiple back ends that implement ISO Common Encryption
instead of the back ends adapting to a standard message format.

You mention a license server. What role does a license server play in
a streaming scenario? Is a license server something other than the
server that under your proposal sends the protection system-specific
initialization message? Or is the license server a synonym for the Web
site that serves the HTML and JS that load the video from a CDN?

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

Why does the CDM need to talk back to a license server? If the user
has paid to see a movie, why isn't it enough for the site that
accepted the payment to send a message *to* the CDM that allows the
CDM to decrypt movie bits downloaded from a CDN? The site should know
what AES key it has used for that particular movie, right? Why is
there a need for a message to a license server to flow out of the CDM?

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

Proceed with a single royalty-free standard to build a large
addressable audience that will weigh in favor of later acceptability
by those who initially reject all RF solutions.

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

The scenario where browser vendors all try something and come ask you
if let them play given what they came up with is fundamentally
contrary to the purpose of standards as an enabler of a level playing
field where a browser vendor doesn't need ask permission from anyone
in order to build a product that renders the Web.

>> Such a barrier seems antithetical to the
>> purpose of W3C specs.
>
> We're not proposing to embed such requirements in any W3C specification.

You are proposing making such requirement de facto part of what
features browser expose to sites, though, so keeping it out of W3C
specs doesn't make the outcome better.

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

An M by N matrix of devices blessed by sites doesn't look like a
particularly scalable solution. Also, standards exist to avoid having
to have such blessing matrices. Proposing a standard that assumes such
a blessing matrix doesn't make sense.

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

I don't think parties who want their content on the Web are entitled
to require the Web platform to become non-RF.

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

Seems like you are when "the platform" means the actual platform
exposed to Web sites to deploy content to including parts of the
platform that you deliberately leave undefined in the proposal.

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

H.264 is a huge problem and it's harmful to the Web that several
browser expose H.264 decoding to the Web without first arranging H.264
to become RF.

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

Sites could choose to target only CDMs whose proprietors impose
onerous terms for integration so the "choice" would be whether or not
to accept onerous terms.

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

Fortunately, that's a theoretical converse. Software authors aren't
enforcing or seeking to enforce their manner of licensing in way
that's harmful to movie authors.

(If movie authors think they are, one should take it with a large
grain of salt considering that interests representing movie authors
have a notoriously bad track record at recognizing what will end up
expanding their business and what's actually harmful to them. See
Boston Strangler. Right now, what's harming movie authors the most is
their own refusal to address demand--often to the point of refusing to
make sales of a particular movie at any price in some territories--not
any sort of software licensing enforcement.)

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

A CDM isn't substitutable with another if the two CDMs don't play all
the same content.

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

Received on Monday, 5 March 2012 11:52:39 UTC