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

On Mar 5, 2012, at 3:52 AM, Henri Sivonen wrote:

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

I think the reason is IPR. Yes, one could easily define such a message format that sends the key in such a way that only the CDM can see it. IANAL, but I'm told that you would then be in an IPR minefield.

As mentioned in my other mail, it is not ridiculous to suggest that CDM vendors effectively give away the client side.

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

The license server is the server side peer of the CDM. It receives a 'key request' message from the CDM (via the application). This message contains some evidence that the CDM is genuine. It responds with a message containing the key, and possibly other information, encrypted so that only the CDM can extract it.

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

Because it is the license server that contains the CDM-specific IPR-laden functionality to verify that the CDM
requesting the content is genuine and to encrypt the key to be sent to the CDM.

Btw, an alternative architecture is that the CDM establishes its own side-channel communication with the license server. We think our approach of proxying these messages through the application has many advantages as described in other mails.

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

As noted above, I think it will be difficult to find a completely RF solution which meets content provider requirements.

I'd be very happy to be proved wrong about that, though.

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

One of the points of the proposal - at least the possibility to combine it with common encryption - is exactly to avoid this M by N matrix.

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

I agree with that. It's not what's proposed.

The "Web Platform" is what is defined by W3C. It's RF and should remain so.

The "Web" is what is exists in the world. It is not defined as "the set of services which can be supported by the W3C Web Platform alone". The W3C works towards goals for the web as set out in its mission, but it does not "own" the Web. I think it would be a very bad thing for anyone to "own" the web.

Many services on the web rely on non-RF technologies delivered in plugins. We are proposing an alternative way to provide some of these technologies, so that these services can make more use of the web platform than they do today.

If you propose to restrict the services which can be offered on the web in any way, you restrict innovation. Just as evolution in constrained environments produces dodos.

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

Those parts would be no more part of the W3C web platform than Flash or Silverlight.

> 
>>>>> (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 much more harmful to restrict people's freedom to use the technology of their choice to offer services on the Web.

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

Sites could choose that, but why would they ? Why would any site unnecessarily restrict their potential audience ?

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

My point, which I think you may have deleted, was that we have no right to take either of these positions.

You have argued mainly about RF above, but if you had been arguing about Open Source in the GPLv3 sense, and saying that the Web (as it exists in the world) should only support services that can be implemented in GPLv3 software, they that *would* be arguing that the licensing choice of software authors be enforced in a manner harmful to movie authors (because their content could not then be distributed on the Web under their chosen license terms).

I'm not sure if you're saying this, as RF != FOSS.

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

There are a lot of comments about the supposed folly of the movie industry in this thread.

But what's far more important than what the movie industry does or does not do is their freedom to offer their products in the (legal) manner of their choosing. You may disagree with what they do or say, but you should fight for their right to do or say it.

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

This is an argument for requiring common encryption in our specification (for each media format). Then CDMs would be substitutable - to the extent they met robustness requirements. Fine by me.

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

Received on Monday, 5 March 2012 17:55:44 UTC