- From: Mark Watson <watsonm@netflix.com>
- Date: Wed, 7 Mar 2012 17:39:29 +0000
- To: Henri Sivonen <hsivonen@iki.fi>
- CC: "<public-html@w3.org>" <public-html@w3.org>
On Mar 7, 2012, at 12:31 AM, Henri Sivonen wrote: > 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 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)? I'm not an expert in how these systems work internally and we're not proposing to design one in this proposal. What I can say is that all the commercial content protection systems require two-way communication between client and license server. I could take a guess that the server may need to know which of several possible private keys the client has. Additionally, the proposal includes the possibility for CDMs to provide secure proof of key release, which requires communication in the client to server direction. > > 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. That wasn't my intention. Whatever you mean by "Web Platform" our proposal doesn't change its RF status: you can build the north side of a CDM API in RF code just as well as the north side of a CDM API. You need proprietary code on your platform to access all the web today and you may continue to do so under our proposal. But our proposal does open the door to expanding the scope of the RF parts in a way that cannot happen with the status quo. And it admoits the possibility of RF CDMs, which do not find a space in the status quo. > > 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. That baseline is no different from plugins today. That there are additional options for installing CDMs, should be a benefit. > 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. Unless I mis-understand you, you're advocating the "restrictive" goal that I outlined in my other mail. If so, we simply disagree on this. It would be worthy of a discussion at the AC as to which of these goals the W3C should pursue. > >>>> 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. Here is an example where the playing field for browsers is not level today. The plugin capabilities we need for our service are not available on Linux and there is nothing browser vendors can do about it. Our proposal could help with that. > >>>>>> 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? The rights of the respective authors to license their works as they choose. Ok, I mis-worded my statement: of course you personally can say whatever you like, but I don't think W3C should take either of these positions for the reason just above. ...Mark > >> 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 17:40:02 UTC