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


On Feb 27, 2012, at 7:43 PM, Kornel Lesiński wrote:

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

It's a first draft - we're looking forward to working with everyone here in the W3C to develop it into a real specification. That the browser/CDM interface needs to be better-defined is good feedback.

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

It's not an identical problem because of the highly-constrained and much reduced functionality CDMs (will) have compared to plugins.

Regarding interoperability, what is important is to have a common encryption system across schemes. It's not addressed in the document because it's an issue for container formats. For example ISO has recently defined such a system for the ISO Base Media File Format (mp4).

With a common encryption system, a single file can be decrypted using multiple protection systems. The draft is intended to support this, with the possibility for the application to choose from the possibly multiple keysystems that are supported by both the file and browser/device.

Thus a single content file can be played on different browsers supporting different CDMs, provided the CDM support the container's common encryption system and provided the application supports that CDM.

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

I couldn't agree more and this is a primary reason for routing the content protection messaging via the Javascript application.

What is intended is that user accounts, authentication and authorization are handled by the application, not the DRM system. The DRM server is shown in our architecture picture as a back-end server that provides only licences for authorized users, with a single set of front-end servers that handle service-specific business logic.

This is one of the reasons why we need extensions to HTML. Without those, then as you say it is a complete PITA to have to stand up separate DRM-specific servers and duplicate account and business logic in each somehow.

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

I think the difficulty is reversed. Integration between my front-end server and a handful of back-end license servers is not so hard, even if they speak different protocols. Dealing with multiple drm-specific over-the-network client protocols and standing up front-end servers for those would be much harder.

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

Fair point. As I said, it's the first draft.

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

I think I answered some of your question above, but yes, of course there is work to do on the details. I think you overestimate the amount that remains, though.

> 
> 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 04:31:09 UTC