Re: Encrypted Media proposal: Summary of the discussion so far

On Sun, Mar 4, 2012 at 08:49, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Sat, Mar 3, 2012 at 5:54 PM, Christian Kaiser <kaiserc@google.com>
> wrote:
> [...]
> > As seen by a client side JS application, all CDMs work the same way. All
> > that is protection-system specific are the (potentially opaque) messages
> > passed to and from the CDM to deliver the key that is required to decrypt
> > the media format to be played.
>
> Given that CDMs are a necessary portion of the proposal, and that
> reverse-engineering common existing DRM schemes is illegal under US
> law and some other countries, the fact that this does not specify CDMs
> in detail is a *weakness* of the proposal, not a strength.
>

Why do you think so? What would we gain from specifying how one or the
other CDM works in detail?
Would we gain from all possible applications of <object> being specified,
too? If not, why not?

I doubt ClearKey satisfies the contractual relationships that the
> intended users of this spec are currently bound to.  If it did, we
> could simply require it; it's more-or-less similar to WOFF packaging
> of a font.  A WOFF font is essentially a TrueType font with an extra
> header prepended to it (there can be additional changes made, but
> they're optional).  One of the primary motivations for this was to
> provide a trivial hurdle between people downloading a font from the
> web and using it in their system.  This was enough to satisfy the font
> foundries who wanted to "protect" their fonts, and it was sufficiently
> easy to work around that it was acceptable to those of us who abhor
> DRM on general principles.
>

I cannot speak to any contractual obligations.
However, I would bet that for *some* applications the protection that
ClearKey affords can be satisfactory.
I would also bet that a mechanism that is implemented in hundreds of
millions of browser installations is attractive for content owners.
Another bet: given lowered barriers to entry, we will see additional
options beyond Clear Key and the commercial CDMs we know today.
Unfortunately, I can't back up these bets with anything concrete. They just
seem like safe bets.

> It seems that *today*, in order to enable playback of many types of
> premium
> > content, a CDM that implements a commercial content protection system is
> > required, since *today* only these can reach the required levels of
> > robustness, and therefore the necessary level of trust.
>
> Your emphasis seems to suggest that, in the future, content producers
> won't require their DRM to be as inconvenient for users.  While I laud
> this goal, what evidence do you have for the implication?  I believe
> the historical trends point to distributors coming up with ever more
> elaborate ways to inconvenience their customers in the quest for
> "robustness".
>

I don't have evidence, but I trust the ingenuity of smart engineers to come
up with innovative approaches in this area, and I trust users to vote with
their feet and give their business to providers of better solutions.
IMHO, historical trends have shown to move towards solutions that are less
restrictive and easier to use. Netflix is a great example here.
This trend could be accelerated if barriers to entry are lowered - for
content distributors and perhaps also for CDM creators.

Will content owners stop requiring content protection mechanisms? I do not
know.

Let's ask a related question: Will physical store owners stop investing in
theft prevention technology (whatever it may be - watchful eyes, cameras,
RFID, ...)?

I believe the answer is based on simple economic principles. (Please note
that I'm not making a judgment here, just describing what I believe to be
the forces at work.)

The threat in this scenario is lost revenue through unauthorized use /
theft.
Both content owners and store owners probably make the following
calculation: What is the cost of the prevention technology, and what's the
amount of potentially lost revenue it prevents? If the former is
significantly lower than the latter, then it's a smart economic choice to
put the prevention technology in place.
Is it wrong for content owners to require prevention technology?
Is it wrong for physical store owners to do the same?

Granted, it's quite well defined what constitues theft in the physical
store example, while there are interesting disputes about what exactly is
unauthorized use of digital content. Clearly, content owners are taking a
side in these disputes that others vehemently disagree with. I would guess
that in the end, we'll need lawmakers help figure this out.
There's also a dispute as to whether there is actually any lost revenue,
and whether content protection technology prevents any of this loss. That
dispute is IMHO fruitless, because it's clearly up to the seller of the
goods to decide that.


> > Members would like more clarity in this area to better understand the
> > consequences of the proposal on the browser market.
>
> As noted multiple times in the thread, the fact that *someone* has to
> pay for licensing the CDMs in use is incompatible with the W3C's goals
> of producing royalty-free specifications for the web.
>

The specification of the proposal is royalty-free, same as the spec for
<video> in general. Any browser vendor is free to plug in a H.264 decoder
(or any other decoder that requires license fees) into their implementation
of <video>.
Does having a licensed H.264 decoder broaden the applicability of a browser
that includes it? It seems like a safe bet to say that it does.
So it doesn't seem to be that different.

Has the ability to plug in different decoders into <video> enabled
innovation? IMHO, it has. I'd point to WebM as a great example.

Many other of the attributes you list are also negatives for the open
> web.  All the browser vendors have been burned by including or even
> just interoperating with closed-source code before, because they're
> unable to fix security bugs in said code.  Platform-dependence is a
> negative for any technology, but it's *particularly* bad for CDMs,
> since reverse-engineering a DRM system (to implement it on your OS) is
> illegal in the US and other countries.
>
> A plugin system for CDMs offers no improvement over the current state
> of affairs, where plugins (Flash or Silverlight, generally) are
> commonly used to play video.
>

So do you propose to leave things at status quo, and leave the premium
video playback capabilities to proprietary closed source UI/execution
frameworks (that take advantage of an existing, much more broad plug-in
system)?
I don't see how the proposal is not an improvement.

Provocatively, should we have not specified <video> and left video playback
to Flash etc. because <video> obviously could be used with H.264?


Let's try a different angle:
What if CDMs are just an interface to content protection systems that are
implemented as part of the OS's media stack? In that case, the CDM could be
open source since all they do is invoke system calls, and implemented
freely in every browser that runs on that particular operating system.
Would that change things?


> It therefore limits or prevents some platform lock-in strategies, e.g.
> where
> > the content protection system is tied to a proprietary UI framework or
> > proprietary media formats.
>
> CDMs are not interchangeable in the sense required for this paragraph
> to make sense.  If a distributor encrypts their videos with a
> particular encryption scheme implemented only by a particular CDM
> which is strictly licensed to only certain browsers/OSes they like,
> they anyone not on their list is unable to play the video.


As Mark Watson has already outlined, the proposal aims to solve this
problem by its inherent support for encryption that is specified by the
media container format.


> > It lowers the barrier to entry for anyone intending to develop a new CDM
> by
> > creating a way to do that without having to also invent and support a new
> > media stack or even a whole UI framework to achieve broad adoption. This
> > enables increased competition and innovation in this area, much of it
> likely
> > towards user benefit.
>
> It enables increased competition in the space of DRM schemes.  You
> assert that competition in this area would be to user benefit.  Could
> you provide some reasoning for this claim?  The historical trends
> point to innovation in DRM producing things that are ever less
> convenient for users.


I dispute that claim (see above). My example is Netflix (or hulu, or Amazon
instant videos, etc...). What examples can you provide?


>  If we were still in the good old days, we'd
> unencrypt the video using a random word from the back cover of the
> movie's box.  Now I have to let a distributor install a rootkit in my
> system, have a persistent internet connection while using the program
> even if it doesn't use the internet in any way, and can't change my
> hardware too much without begging the distributor to unlock my
> property again.
>

You're making a general statement that may be true or have been true in
some particularly egregious examples, but wrong in general.

This assumes that the CDM is open-source and royalty-free.  Neither of
> these are true of current CDMs, and so implementing multiple of them
> is still costly and difficult.  I don't believe any of the current
> targets for this specification intend to produce and use CDMs which
> are open-source and royalty-free, either.
>

So should we leave the status quo as is? What would you suggest we do to
get closer to a solution?

Christian