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

On Mon, Mar 5, 2012 at 08:48, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> 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:
> >> [...]
> >> 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.  ^_^
>

Let me push on this a bit. If you're saying that <object> was a horrible
idea, does that mean you'd rather have had a world where web video was
impossible until the first implementations of HTML5 with <video> support
came out?
A world where all the great innovation that NPAPI plugins enabled would
have been impossible?
How would that world have been better than the one we experienced?


> There's a reason the language has <img>, <iframe>, <audio>, and
> <video> - specialized elements work better than catchall-with-plugins
> elements.
>

I agree.
But it sometimes takes the standards a while to come around to specify
something, and some things will never be standardized, e.g. if they are
just too far on the fringes. Should these things be prevented from
existence (or forced to invent their own web to be able to exist)?
If so, why do you think that's a good model? There seem to be tradeoffs
here.

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

I would dispute that the situation with video codecs is "bad for
everybody". It seems that there's a pretty workable model in place today.
Not perfect, but workable.
What do you think would have happened if H.264 in <video> would have been
excluded from web standardization?

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


I think this is an important point, but I don't understand it yet.
Can you provide more details on how you see the web being saddled? What
does "being saddled" mean in this context, and why do you think it is a bad
thing?

 Even
> if a free, open-source CDM like ClearKey eventually wins, there'll be
> some collateral damage.
>

What is the damage?
Sorry to be so probing, but I think it's important for the group to
understand where exactly the sticky issues are.

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

Implementing the ClearKey CDM would certainly be better than nothing. But
it would not satisfy some requirements.

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

What if your theory is wrong, and content owners will continue to require
content protection (e.g. because they decide it's a good economic tradeoff
for them)?

Why do you think the video game industry hasn't made that decision yet? You
could argue that in some sense, video games are more like movies than music
is like movies - few assets, high production value per asset.

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

True in some cases. They also can't innovate if the barrier to entry is too
high. Lowering the barrier to entry is one of the IMHO positive side
effects of the proposal at hand.

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

I don't understand your concern, but would like to. Please help me
understand what you mean with "obscene level of monopoly rights ove the
content they distribute" and "required to beg the movie industry for the
right to even *be* a solution".


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

I'd love to see concrete examples for your contention that DRM gradually
got worse, then broke down. You're making a very general statement here.

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


You nicely sidestepped my question on a technicality :-). Let me clarify:
for physical stores, the threat is theft. For content owners, the threat is
unauthorized use. Both result in some loss of revenue. Both can be
partially (but not perfectly) mitigated with some kind of prevention
technology.
I'm still curious what your take is.

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

I'm not holding up H.264 as a positive or negative example. In fact, I'm
trying to avoid making judgements about anything that is outside of the
discussion about the proposal. I brought up H.264 because the situation
there seemed fairly analogous to some aspects of the proposal, and I wanted
to understand if and why your assessment differs.
That's why I asked.

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


Thanks, that helps me understand your position better.

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

Would that scenario be *more* acceptable, or equally unacceptable?

Christian