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

On Mar 5, 2012, at 5:06 PM, Tab Atkins Jr. wrote:

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

Standards are one thing, but your position seemed to be that there was no value in any non-RF work. That's pretty sweeping.

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

Sure. But the argument has been made again and again that "they should change their mind" is the solution to this problem. I'm saying, no, that's up to them. So what is the solution to the problem of providing commercial video on the web ?

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

Apart from support for commercial video services, yes.

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

Oh, so you're saying that the supposed unpleasent-ness of the DRM parts is mitigated because it has all this extra functionality ? Wouldn't the unpleasent-ness of CDMs be similarly mitigated by the possibility to integrate with all the extra functionality of the web platform ? More so, surely ?

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

That may be true, but it's not exactly a strong argument compared to the others we are discussing. Remember that the *whole business* of a content protection provider rests on their ability to write secure code.

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

It does if the "free-er" one is not as good.

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

That makes no sense as an analogy. A sufficient analogy is just that some geo-location services are better (more accurate) than others.

> 
> 
>>>>> 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 said _slightly_ different. You may not think it's significant. I just didn't say what Netflix would or wouldn't be doing.

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

That argument depends on us agreeing that it's an "infection". If we agreed on that there would be no debate here.

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

We can't and shouldn't embed in a specification things that only follow from the current market, of which we have imperfect knowledge anyway.

I don't think anyone has tried to hide the fact that this initiative is intended to support content protection requirement or what those currently include.

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

When a product if offered for sale, it is the seller who determines the product's features. If it is not what you as potential buyer "desire", then don't buy it. You don't have a right to make sellers offer you the product you desire.

I seems that you feel that, for example, since you desire to watch a video anywhere in the world, you should be able to buy that product, but it just isn't so. It's up to the seller whether to sell you that or not and on what terms, unless there is actual government regulation of those terms. If I want to sell a video streaming service which does not work on Saturdays, I've a right to sell that. Some people may prefer that product if it was cheaper than a 7-day a week one. If I want to sell a video streaming product whihc requires H.264, I've a right to sell that too. And if I want to sell one which requires content protection, there's no difference.

Users express their desires in the marketplace, not through standards organizations. If users don't buy a product they think is dumb, they won't have to suffer it's marketing much longer.

So, yes, a preference option which allows users to turn off content protection (and so only access products which which don't need it) is a fair balance between producers and consumers. You get to control what runs on your computer and the producer gets to choose how their own product will work.

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

Right, and W3C has agreed privacy objectives which justify that stance.

>  Some sites
> would test for that and simply not work if users refused to give up
> their privacy.

I trade my private information for services all the time. If I think someone wants too much private information, I don't use or buy their service. As long as users are in control and the default is to privacy, this is fine.

>  It's better for our users if we prevent users from
> ever having to make that choice.

 'Prevent users from making a choice' - why am I skeptical of this statement ?

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

If by 'open web' you mean the subset of the web which can be accessed using purely RF Open Source software, then this is fine. This is a reflection of the right of software authors to license their products on their terms: for example with GPLv3, thereby preventing implementation of exactly the features some copyright owners require.

But this 'open web' is not the whole web. And W3C standards already provide hooks for non-RF software to be plugged in. Trying to restrict the whole web into being only what you call the open web is unreasonable and even dangerous. What we should do is try to expand the open web to encompass as much as possible of the real 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 04:48:49 UTC