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

On Mon, Mar 5, 2012 at 4:31 PM, Mark Watson <watsonm@netflix.com> wrote:
> On Mar 5, 2012, at 1:07 PM, Tab Atkins Jr. wrote:
>> On Mon, Mar 5, 2012 at 12:22 PM, Mark Watson <watsonm@netflix.com> wrote:
>>> On Mar 5, 2012, at 11:54 AM, Tab Atkins Jr. wrote:
>>>> On Mon, Mar 5, 2012 at 11:19 AM, Mark Watson <watsonm@netflix.com> wrote:
>>>>> So, I think this would be a very bad thing, since these have been venues for innovation in the past and it would be detrimental to progress in general to remove such venues.
>>>>
>>>> I don't believe that royalty-encumbered technology is required for
>>>> innovation.
>>>
>>> I agree. Did I say otherwise ?
>>
>> Your argument is that it's important to let royalty-encumbered
>> technologies work on the web, because of the innovation potential they
>> bring.  I argued (somewhat tersely) that royalty-free technology
>> innovates pretty well  by itself, such that the cost incurred by
>> bringing royalty-encumbered stuff into the platform isn't worth the
>> additional innovation benefit.
>
> You have a great crystal-ball, then. Adjusting - again - to align with the proposal, which does not bring royalty-encumbered stuff into the platform any more than plugins do, that is still a tremendously sweeping statement about our industry.
>
> You really think it would be wise, forever more, to restrict web innovation - even if you could - to only those things where the client can be 100% royalty-free ?

It's worked so far, for the most part.  We make the occasional
exception when necessary, but nearly all of the platform is RF.  The
W3C generally requires specs to be RF, as do many other of the
standards bodies dealing with web-platform technologies.


>> If copyright infringment is not something that desperately needs to be
>> dealt with (clarification: dealt with on a technical level, rather
>> than contractual/economic/legal level), why are we attempting to
>> introduce DRM to the web platform?  DRM is solely a mechanism that
>> attempts (unsuccessfully) to slow/stop copyright infringement.
>
> I was objecting to the 'horrifying job-killer' part. A problem does not need to be 'desperate' to be worth working on.
>
> But again, this is a decision for the authors of the works, not for us.

Ah, ok.  I was indeed being hyperbolic there.

Copyright owners can indeed make the decision to ignore economics and
demand DRM in order to distribute the works they own.  They can't make
the decision for us, though, to support their decision.


>>>>  Whether or
>>>> not you think that sharing is morally right or wrong, it's clearly not
>>>> an enormously important issue that would justify baking closed-source,
>>>> royalty-encumbered technology into the web platform.
>>>
>>> That's not what is proposed, any more than Flash or Silverlight is 'backed into the web platform'.
>>
>> For most practical purposes, Flash *is* baked into the web platform.
>> A few years ago, every browser was *required* by market forces to
>> support Flash.  Thanks to the efforts started by iOS, the trend is
>> reversing, but it's still something you probably need if you want a
>> popular desktop browser today.
>
> So, what does this say to you ? What are market forces other than the expression of the desires of consumers ? Doesn't this mean that consumers are demanding functionality that, for whatever reason, is not part of the web platform and therefore has to be provided in a plugin ?

Indeed!  The web platform effectively froze for a decade while IE was
dominant.  During that time, innovation happened outside the web, in
the form of plugins like Flash.  Since we've unfrozen, we've caught up
with the major functionality of those plugins (and in a royalty-free,
open-source way!) and are keeping pace.

If such a catastrophe ever happens again, we can reevaluate the need
for royalty-encumbered technology.  For now, though, we're doing
pretty good sticking with RF.


>> Further, if a spec was proposed that required an unspecified external
>> technology to plug into it, and it was clear that most actual users of
>> the specified tech were going to use Flash or similar, that would be a
>> significant drawback.  And Flash is much *less* objectionable than DRM
>> blackboxes.
>
> SilverLight at least *contains* a DRM black box. How can the whole be less objectionable than one of its parts ?

I can't speak for Silverlight, but Flash at least is much better
understood.  It's not open-source, but it's been natively
reimplemented by at least Chrome.  It also has a bunch of utility for
authors and users outside just being a DRM box.


> And I really don't understand the objection to APIs that access external technology. What about the Geolocation API, for example ? Many implementations of this will use proprietary technology, or even paid-for back-end services. Those that don't likely won't perform as well - won't support as many services.

Not all black boxes are created equal.  For example, an external
geolocation API is much less likely to be a source of security bugs
and integration pain than something trying to insert itself into the
media rendering pipeline.

Additionally, even if particular implementations choose to use a
proprietary or even licensed service, it doesn't hurt *other*
implementations if they choose to use a free-er one.  A somewhat
appropriate analogy would be if some locations only allowed themselves
to be located by certain geolocation services, and it was illegal for
non-licensed services to locate them.  If that was the case, then
proprietary geolocation stuff would be a much bigger deal.


>>>> This whole tangent is irrelevant, though.  DRM does *not* stop
>>>> copyright infringment (see list item 1, above); apparently, it doesn't
>>>> even slow it down to any significant degree.  I don't think one can
>>>> reasonably argue that adding DRM to the web platform will have
>>>> materially different results.
>>>
>>> Aside from that not being what is proposed (again - can we stop with repeating this one?)
>>
>> It is being proposed, it's just not in the spec.  You personally
>> stated that Netflix would be using a CDM that implements "real" DRM,
>> not something like ClearKey.
>
> I said that I doubted clearkey would meet the requirements of our contracts today. That's slightly different.

Hm, I don't see a significant difference between our two statements.
Can you elaborate?

> I just fail to see how it is different from proprietary plugins or codecs: these things are not defined in the specification. It's not required to implement them to be compliant to the 'web platform'. Yet the hooks to access them are.
>
> I can't help it if 'market forces' make Flash or anything else de-facto mandatory - I seem to be lacking both the crystal ball and the omnipotent market influence that you expect.

Indeed, you can't help it.  But we can prevent the infection from
spreading beyond the current plugin-pit, where it's less likely to be
required to support web content in perpetuity.

We can also force specs to be clear about the fact that they're de
facto requiring closed-source and/or royalty-encumbered technology in
implementations, rather than allowing them to hide behind a
trojan-horse tech that will see little to no use.  It's dishonest to
attempt to claim that a spec does not include DRM and does not require
closed-source and/or royalty-encumbered technology when it will, in
practice, require precisely that.


>>> , one can reasonably argue that the response to much of the above is up to the owner of the copyright. If they choose to license it a particular way, they're entitled to do it, whatever you think.
>>>
>>> *Given that*, we have some choices about how to support services that use that content. Stay with plugins or adopt something along the lines we propose.
>>>
>>>> Finally, authors' rights are a legal and contractual issue, not a
>>>> technical one.  You can have both strong copyright *and* DRM-free
>>>> distribution.
>>>
>>> The author has a right to specify in their license properties that the technical means of distribution must have. So it is a question of author's rights.
>>
>> Sure, and I have a right to require any browser I use to not
>> interoperate with closed-source blackboxes that impair my computer's
>> security.  So it's a question of user's rights.
>
> I agree you have that right. This proposal would help you exercise it. Your browser could inform you about CDMs and you could turn them off. Unlike today, where you have to forgo Flash/Silverlight and all the non-DRM functionality they provide in order to exercise that right.
>
> Both you and the content author can have their rights respected - it doesn't have to be a choice.

In effect, you're claiming that offering a "Do you want to be able to
watch videos? Y/N" dialog is sufficient for respecting our users'
desires.  I and several other browser developers do not agree that
this is the case.  We believe that the demands of content distributors
are unreasonable.

We've made decisions in the past to help avoid letting sites make
unreasonable demands on users.  For example, it would be unreasonable
of us to generate a unique ID for every browser install and expose it
to the general web for easy tracking, even if we allowed users to turn
it off and revert to today's qualified semi-anonymity.  Some sites
would test for that and simply not work if users refused to give up
their privacy.  It's better for our users if we prevent users from
ever having to make that choice.

In effect, we're choosing a different way to honor both parties'
rights - by simply preventing copyright owners that try to require
such things from using the open web.  Their personal contract
preferences are still respected, and so are our users' rights.


>> If we set aside the rhetoric, you're attempting to argue that we
>> should honor the copyright owner's wishes at the expense of all the
>> downsides that have been previously listed in these threads.
>
> Yes, because I believe those downsides are either soluble or not so bad as to be worth hobbling HTML5 video by refusing to provide the hooks needed for most commercial video content.

Several implementors that have commented so far disagree that the
downsides are either soluble or "not so bad".

~TJ

Received on Tuesday, 6 March 2012 01:06:51 UTC