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

On Sun, Mar 4, 2012 at 7:25 PM, Christian Kaiser <kaiserc@google.com> wrote:
> 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?

<object> isn't a good example, as it was a horrible idea.  ^_^
There's a reason the language has <img>, <iframe>, <audio>, and
<video> - specialized elements work better than catchall-with-plugins
elements.

If a spec *requires* a certain piece of technology, that technology
should be specified, either alongside it or in a companion spec, so
that we can be sure the entire technology spec is implementable by
arbitrary browsers and is royalty-free.  An example of when this
*didn't* happen and it was bad for everyone was video codecs - some of
the in-use codecs aren't royalty-free, so they can't be implemented by
arbitrary browsers.

If you don't specify a required piece of technology, you're just
writing an incomplete spec.  Might as well be honest and plaster a big
"TODO" across the spec.


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

Luckily, we have people from a relevant company (Netflix)
participating in the thread who *can* speak for their own contractual
obligations.  If *no one* is willing to speak for their contractual
obligations, then I think we should assume that there are no such
obligations and act according to our best judgement.

I'm not willing to make either bet when, if I lose, the result is that
the web is saddled with multiple royalty-encumbered DRM engines.  Even
if a free, open-source CDM like ClearKey eventually wins, there'll be
some collateral damage.

You argue above that a mechanism that is implemented in millions of
browser installations will be attractive for distributors.  A much
safer bet, then, is to implement *only* the ClearKey CDM or something
similar.  If you're right, it'll be good enough, and we don't end up
with DRM in the web platform (just a light encryption barrier, similar
in principle to WOFF).  If you're wrong, we've just wasted some time,
and plugins continue to be used to deliver video.

I would argue that there's another fairly safe bet we can make, which
is that if we simply do nothing, market pressure will eventually force
the distributors to drop their DRM requirement and they'll just use
the existing <video> element to ship video to their customers.  In
this case, if we're wrong we haven't lost anything - plugins continue
to be used to deliver video, exactly like today.


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

Engineers are generally unable to come up with innovative approaches
when their hands are tied by contracts and anti-circumvention laws.

As well, Congress has granted the movie industry an obscene level of
monopoly rights over the content they distribute.  Users are unable to
vote with their feet when all the providers of solutions are required
to beg the movie industry for the right to even *be* a solution.
Evidence suggests that innovation is largely frowned upon in these
sorts of things.


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

I greatly disagree with your analysis of historical trends.  Based on
industries that reached the web earlier than video, my reading of
history is that DRM got gradually worse and more intrusive, until the
whole thing broke down and suddenly the distributors were willing to
send out DRM-free content.  Only *then* did it finally become easier
for customers.


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

The SCOTUS has made it quite clear that copyright infringement is not
theft.  Please do not attempt to use this analogy, as it is both
grossly inaccurate and dishonest.  I am disappointed that the rhetoric
has reached this, as it's nearly to the point of accusing browser
vendors of promoting theft.


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

This is irrelevant.  The spec *requires* another piece of technology
that is not specified, and which is commonly royalty-encumbered (and
further, though royalty-free versions of the tech exist, we expect the
royalty-encumbered versions to be the ones that are actually used).
Thus, this spec is attempting to include royalty-encumbered technology
in the web.

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

The core of WebM was not enabled by <video>, since it's just VP8, an
existing codec.

The fact that <video> allows H.264 is unfortunate, but necessary given
history.  It is bad for the web, since any content encoded with H.264
is not viewable in Firefox, Opera, or pretty much any niche browser.
Only IE, Safari, and Chrome can view it (and maybe other webkit-based
browsers? I dunno).

Further, it seems frankly *bizarre* for a Google representative to
hold up H.264 as a positive example when we (Chrome) made a promise
over a year ago to *drop* H.264 support because of how troublesome it
was for the open web; we have yet to honor that promise, but I'm aware
that we are still working toward it.  I know that we as a company
rarely, if ever, have a coherent voice, but still, mixed messages.

Royalty-encumbered technologies are a *mistake*.


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

It's not an improvement.  It's the status quo.  That's the point.

By keeping the status quo, we don't make things *worse*, like by
baking a royalty-encumbered technology into the web platform.  It also
allows the rest of the world to continue around us and hopefully
evolve into a friendlier state.  The history of other DRM-obsessed
industries suggests that they all eventually crack and sell to their
customers without DRM, at which point we can happily point to the
existing <video> element that we've been offering them for years
already.


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

If H.264 was the only serious codec proposed to be used, we probably
wouldn't have specified <video>, yes; to do so would have been baking
a royalty-encumbered technology into the spec.  Luckily Ogg was a
viable contender, and then we introduced WebM, both royalty-free.
Major browsers committed to supporting both of these, so we could
swallow the lesser pill of simply *allowing* royalty-encumbered tech
onto the web, since we assumed that the royalty-free stuff would win
in time.  I still think it will, eventually.


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

No, it keeps us in exactly the same position.  You still have a
closed-source, royalty-encumbered piece of technology required as part
of the stack.  You're just moving where it's implemented.  This means
that, rather than niche browsers being excluded, niche OSes are
excluded (where "niche" likely in practice means "everything but Mac,
Windows, and the mobile versions thereof").


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

As Henri Sivonen has responded, this isn't good enough.  They're still
not substitutable.


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

Streaming services are roughly the apex of current convenience,
because customers inherently don't expect many of the qualities that
they do when they buy a video or watch normal TV.  The fact that DRM
kills those qualities is thus irrelevant.

They're definitely not icons of convenience, though.  For a trivial
example, I am unable to watch Netflix on my work laptop (which I take
with me everywhere on trips), because it runs Linux and Netflix
requires Silverlight for its DRM.  Assuming I take my personal laptop
which runs Windows, I am unable to queue up videos and pre-download
them for watching on the plane.

Within the movie industry, look at massively inconvenient failures
like Ultraviolet.  In other DRM-happy industries, look at the history
of rootkits in the music distribution industry.


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

No DRM scheme contains all of those (I hope...), but many contain at
least one or a close variant, and there are other little
inconveniences that every DRM scheme has.


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

As I suggested earlier in this email, the best solution for the web is
to wait for the movie distributors to crack and agree to sell videos
without DRM.  We can *afford* to wait, after all, since the status quo
works.  The falling rate of plugin installation, though, hurts the
distributors as long as they insist on using them for DRM.  Copyright
infringement, as well, will only continue its upward trend, which
doesn't hurt the movie-*making* industry, but does hurt the arms of
those companies that make money off of plastic discs.

~TJ

Received on Monday, 5 March 2012 16:49:48 UTC