W3C home > Mailing lists > Public > www-tag@w3.org > October 2014

Re: Comments on the EME opinion

From: Mark Watson <watsonm@netflix.com>
Date: Thu, 23 Oct 2014 13:35:30 -0700
Message-ID: <CAEnTvdCLikEmOqHJqJJ1gBq7drqdJ7piaaNTpFnOJLHnA43JrQ@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: David Dorwin <ddorwin@google.com>, Henri Sivonen <hsivonen@hsivonen.fi>, www-tag <www-tag@w3.org>
On Thu, Oct 23, 2014 at 11:06 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> From: Mark Watson [mailto:watsonm@netflix.com]
> > ​It's a UA/CDM combination and probably not in the short term, though
> we'd evaluate on cost vs market share grounds if/when we came to it.​
> This is very concerning and exactly the kind of scenario the TAG is
> against (https://www.w3.org/Bugs/Public/show_bug.cgi?id=27053).

​Well, obviously, it's not something anyone would be "for", if there was an

> It is important for the spec to set a baseline such that no such
> discrimination against different lower-marketshare UA/CDM combinations
> takes place (either because it is technically impossible---hard to imagine,
> but ideal---or at the very least because no technical incentives to do so
> exist).

​Sure. I don't believe there are any such "technical incentives" to
discriminate in our specification, though I may not be understanding
exactly what you mean by that phrase.

>From a business perspective the pressure is totally in the direction of
being on as many platforms as possible (this is also obvious). And it
should be no surprise that businesses make decisions on a cost/benefit
basis. If there existed a solution which allowed us to be completely
platform-neutral we would be delighted and would jump at that. EME is
bringing us in that direction: for example, as I mentioned, Netflix works
in Chrome on Linux without - as far as I know - a particularly tight
binding to the Linux OS, because Chrome/Widevine have provided a solution
with that property.​

> One way of doing this would be to require all UAs to require HTTPS. This
> seems especially important given that smaller UAs may not have the pull
> with DRM vendors to address security and privacy concerns in a different
> way, that works over insecure transports.
> ​
​Large content providers are not all going to migrate to HTTPS overnight.
As mentioned on another thread, I will have some data on server performance
related to this to share soon. The significant costs of this migration will
totally outweigh any W3C fiat and browsers who choose to support only HTTPS
will find their customers either still using plugins, or cut off from
services - a different kind of fragmentation of the web.

Given this, I think it likely that all DRM providers will have solutions
which can be used on HTTP origins. This is what we are doing on IE, Chrome
and Safari today. I doubt they would refuse to provide those same solutions
to smaller UAs (at least for those who provide the DRM as a separate


Received on Thursday, 23 October 2014 20:35:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:26 UTC