W3C home > Mailing lists > Public > public-html@w3.org > February 2012

Re: Missing hardest parts of actual content protection (was Re: Encrypted Media proposal)

From: Kornel Lesiński <kornel@geekhood.net>
Date: Tue, 28 Feb 2012 03:43:58 -0000
To: public-html@w3.org
Message-ID: <op.waddzk1ste2ec8@aimac.local>
On Mon, 27 Feb 2012 21:34:03 -0000, Mark Watson <watsonm@netflix.com>  

> 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

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:48 UTC