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

On Mon, Mar 5, 2012 at 7:55 PM, Mark Watson <watsonm@netflix.com> wrote:
>
> 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.

It's troubling to see spec proposals go into the mode of declaring
defeat in face of patents from the get-go without even trying to
develop an RF solution under the W3C PP.

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

So far no one has stepped forward saying that they own an
already-Hollywood-approved DRM system and they'll 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.

If the key in encrypted so that only the CDM can extract it, what more
evidence does the license server need? That is, why does the license
server need to see evidence before sending a message instead of
relying on its message being undecryptable by recipients other than
the genuine CDM (that possesses a private key)?

It seems to me that adding inessential evidence flows is more likely
to make the system "IPR-laden".

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

To me, it seems that the most obvious alternative architecture is that
the CDM embodies a secret (private key) and the server sends a message
that's decryptable using the secret and there's no data flow from the
CDM to a server at all. I'd like to understand why such an
architecture isn't considered sufficient.

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

You've defined the "Web Platform" as excluding JavaScript. Seems like
a radical definition.

By "Web platform" I meant the platform that browsers expose to sites
for them to run their client-side stuff on. You are proposing
"IPR-laden" CDMs to become part of that platform. Whether that part is
defined at the W3C is a side issue when considering what browsers need
to expose to Web sites.

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

We disagree. I think its harmful to enable technology choices that end
up restricting the freedom of others.

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

Netflix's non-support for desktop Linux indicates that they would. You
are in a better position than I to answer the "why" part.

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

What's restricting our right to take positions?

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

I completely disagree that I should fight *for* their "right" to do 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.

Would it be fine by you to have substitutable implementations of a
single description of Web-exposed CDM behavior if the W3C managed to
come up with an RF way of communicating the AES key to the CDM? If the
encryption of media is already constrained to one solution per media
format, allowing CDM vendors inject arbitrary IPR-ladenness into the
process of getting the AES key into the CDM seems like a bug that
doesn't help Netflix and only serves DRM vendor lock-in & royalties.

(Robustness is obviously a characteristic of a particular implementation.)

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

Received on Wednesday, 7 March 2012 08:32:28 UTC