- From: Mark Watson <watsonm@netflix.com>
- Date: Fri, 24 Oct 2014 08:19:41 -0700
- To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
- Cc: Domenic Denicola <domenic@domenicdenicola.com>, David Dorwin <ddorwin@google.com>, Henri Sivonen <hsivonen@hsivonen.fi>, www-tag <www-tag@w3.org>
> On Oct 24, 2014, at 2:32 AM, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote: > >> On 2014/10/24 05:35, Mark Watson wrote: >> >> 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). > > Just a (maybe stupid) question from a non-expert: When you speak about HTTPS, would that require transmitting all the content (huge video files,...) over HTTPS, or would that only/mainly apply to credential exchanges/signup/... or whatever it's called that goes on before the actual content is served? As things stand it requires everything, including the content, to be over HTTPS. If there was a solution that enabled an HTTPS site to retrieve just the video over http, then this discussion would be very different. It is actually easy to imagine such a solution from a security perspective (the HTTPS site provides the UA with hashes of the expected objects to be received over http) but obtaining the same privacy properties as HTTPS is more difficult. ...Mark > > Regards, Martin.
Received on Friday, 24 October 2014 15:20:09 UTC