- From: Mark Watson <watsonm@netflix.com>
- Date: Thu, 23 Oct 2014 13:35:30 -0700
- To: Domenic Denicola <domenic@domenicdenicola.com>
- Cc: David Dorwin <ddorwin@google.com>, Henri Sivonen <hsivonen@hsivonen.fi>, www-tag <www-tag@w3.org>
- Message-ID: <CAEnTvdCLikEmOqHJqJJ1gBq7drqdJ7piaaNTpFnOJLHnA43JrQ@mail.gmail.com>
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 alternative. > > 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 product). ...Mark
Received on Thursday, 23 October 2014 20:35:57 UTC