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

Re: CfC: Create Media Task Force

From: Henri Sivonen <hsivonen@iki.fi>
Date: Thu, 12 Apr 2012 15:19:42 +0300
Message-ID: <CAJQvAudLVTfx4ZyHE9i9knWLR7UYLXu4TBKZbOFX7jzPBY-DTQ@mail.gmail.com>
To: robert@ocallahan.org
Cc: Mark Watson <watsonm@netflix.com>, Paul Cotton <Paul.Cotton@microsoft.com>, "public-html@w3.org" <public-html@w3.org>
On Thu, Apr 12, 2012 at 7:20 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
> One way would be to have the complete workings of the CDM
> documented/specified in enough detail that it can be freely reimplemented;
> this would be ideal, but I don't expect it to happen, since that I assume
> any CDM so documented would fail the Hollywood placebo test.
> Alternatively, for a platform that offers built-in DRM API, you could define
> a CDM that maps onto that API, and explain the mapping in enough detail that
> any UA running on that platform could implement it.
> Alternatively, for a proprietary DRM product, you could define a CDM that
> maps onto that product and explain that mapping in enough detail that any UA
> running where that product is present could implement it.

The two last options above wouldn't enable interoperable independent
implementations of the whole stack even though they could enable
interoperable independent implementations of the W3C part of the

An alternative enabling interoperable independent implementations of
the whole stack while still avoiding describing *everything* about the
CDM publicly (the first option above) would be specifying all the
Web-exposed behaviors of the CDM in a public royalty-free W3C spec
*except* for a small secret key. Robustness against poking via means
other than Web APIs is not a Web-exposed characteristic. The W3C would
then hand the secret key to implementations that defend key material
and clear pixels against external poking to a Hollywood-approved
degree (in order to make Hollywood believe that all of the independent
interoperable implementations are sufficiently robust).

("The" CDM key could change over time, since for streaming use cases
it only matters that's the key is valid during the initial stream set
up. That is, the above paragraph doesn't imply that there would have
to be one secret for all time.  Each CDM key could be valid for e.g. a
week and a new key downloaded weekly by an updater or whatever.)

It appears that an arrangement that separates the behavioral spec
(except for the secret key(s)) from the management of the secret
key(s) works for Marlin in a presumably Hollywood-satisfying way.

This sort of scheme would of course still be worse than features being
interoperably implementable without having get a secret in exchange
for certification from anyone. But this would be better than even the
non-key parts of the CDM being proprietary.

Henri Sivonen
Received on Thursday, 12 April 2012 12:20:20 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:22 UTC