- From: Kornel Lesiński <kornel@geekhood.net>
- Date: Tue, 28 Feb 2012 03:43:58 -0000
- To: public-html@w3.org
On Mon, 27 Feb 2012 21:34:03 -0000, Mark Watson <watsonm@netflix.com> wrote: > By defining a standard architecture and decoupling service-specific and > content-protection-specific aspects, we make it much easier to create a > service supporting a diversity of browsers and devices based on a > diversity of protection systems. I think the current proposal is still very far from achieving this goal. 1. The spec leaves interaction between CDM and the browser undefined, so each CDM provider will have to cooperate with every single browser vendor it's willing to support, and browser vendors may need to implement proprietary CDM APIs several times. Plugins have ActiveX/NPAPI/Pepper fragmentation, but that is better than nothing. 2. Very few companies have enough market power to establish a new DRM approved by "Hollywood", so it's quite possible that the current plugin problem will just morph into an identical CDM problem — the same incumbents will continue using their current "Adobe CDM", "Silverlight CDM" and "FairPlay CDM" with no interoperability. Perhaps definition of a standard, 'neutral' W3C-backed CDM would help break the stalemate between Apple, Microsoft and Adobe and offer some better-than-cleartext solution to Free Software, but there is no spec for that unfortunately. 3. For service providers proprietary DRM media and licensing servers are a real PITA, and supporting multiple of them at the same time (e.g. synchronising user account and authorizing devices across different, closed systems which are very paranoid about authentication and identity) is a nightmare. The spec only tries to tackle relatively easy client-side part which could be done automatically (out of band) by a plugin from each vendor. I think unified server-side API is much much more important to enable diversity of protection systems, but it's out of scope of the spec. 4. The spec does not help implementors create secure implementations. Trivial MIME Type RFCs have "Security Considerations" section, but this spec doesn't even use words "trust" or "attack", which is quite a significant omission for a spec involving encryption/protection. The spec could at least define a standard way to protect licenses/keys from eavesdropping, replay attacks and CDM spoofing, so each implementor wouldn't have to reinvent that. It needs to define chain of trust and how it is established/verified — otherwise each CDM/browser/OS combination may have different, variable and unspecified, levels of protection. There is nothing about revocation of compromised CDMs. Even if some of these things are out of scope, it should be stated explicitly, so implementors know in what areas the spec is insufficient. So even if the intent of this spec was to enable easy and interoperable content protection, it touches only tiny portion of this complex problem and is vague in key areas. Much more needs to be specced before it can reach interoperability level of plugins today. And I'm afraid that content protection is doomed to hit some hard political and business issues that specs cannot solve, and it may always be a mess by the nature of DRM and power structures it creates. -- regards, Kornel Lesiński
Received on Tuesday, 28 February 2012 03:44:25 UTC