- From: Ben Gidley <ben@gidley.co.uk>
- Date: Wed, 22 Jul 2015 08:22:43 +0000
- To: Mike West <mkwst@google.com>, Brad Hill <hillbrad@gmail.com>, Ryan Sleevi <sleevi@google.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CALM79e+-WQuc5CFheAY+zZ=fg1a54dqJ0LsLjdYLdAX+Hdmrug@mail.gmail.com>
I work for Irdeto and we don't have a video player ourselves, but instead do the DRM components. We often see TV operators running our systems in HTTP pages and historically they've been using Silverlight/Flash. They are now moving to DASH/HTML5 using players like Shaka (Google) and Bitdash. We'd like to encourage them to move to SSL for the player page as it helps with some relatively easy ways to trick DRM systems, however many are unlikely to do if it means moving the video CDN to HTTPS. The rationale behind TV operators not wanting to use HTTPS for CDN's is - Most large CDN's do support SSL but may charge for it (CDN bills are usually one their biggest expenses) - Many telcos/TV operators/ISP's have their 'own' CDN. In my experience these tend to be out of the control of the team who own the video websites. This can cause many organisational issues to make changes (e.g. turn SSL on). - The privacy threat (which I acknowledge exists) is not a major business driver for them - Using HTTPS breaks downstream caching - this can be a big deal in some regions. Many ISP's have transparent HTTP proxies for video and using HLS/DASH with HTTP enables them to effectively extend the CDN into their networks for 'free' as far as the operator is concerned. - SSL is not required on DRM'd video from a security point of view - SSL can add to network latency - this can be a big deal on 'fast channel change' scenario's - every millisecond counts there and from a broadcast background even adding 10-20 milliseconds is a 'big deal'. I can't cite any operators this is a blocker for right now - as most are still deploying HTTP player pages, but I'm talking to a number of large operators about securing those pages and this is going to be an issue. At very least it will slow adoption of HTTPS, and may block it in some cases. If we look beyond the DRM video market to general internet video, as people move to DASH I'd expect this to become a bigger deal. If you want sites to move the HTTPS they'll need a HTTPS CDN which adds to the complexity of setup and thus will be a (bad) reason not to either deploy DASH/HTML5 Video or HTTPS. I'd therefore advocate you consider this solution if possible. I've reached out to the Bitdash team to see if they believe that solution is workable (I think it is but as I don't write players it would be good for them to confirm!). Ben Gidley On Tue, 21 Jul 2015 at 17:18 Mike West <mkwst@google.com> wrote: > +Ryan > > On Tue, Jul 21, 2015 at 6:11 PM, Brad Hill <hillbrad@gmail.com> wrote: > >> There was a proposal of this sort (not a blanket exception, but a safer >> way to allow for video-over-HTTP to HTTPS pages) by Ryan Sleevi, the start >> of the thread can be found here: >> >> https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0371.html >> >> We discussed this last week at our face-to-face in Berlin, and the feel >> of the room seemed to be that the proposal was technically sound, we >> weren't sure who exactly the customers of it would be. I think Ryan had >> Netflix in mind given their previous reluctance to move to TLS for >> delivery, but with that resolved, nobody has publicly stepped up as wanting >> to adopt such a solution. Our informal rule of thumb in this group is that >> we've wanted expressions of interest from two "customers" of a feature >> before we start working on something. >> >> Ben, do you maintain a player like this, or know someone who does, who >> would be willing to examine and comment on Ryan's proposal? >> >> thanks, >> >> Brad Hill >> >> On Tue, Jul 21, 2015 at 1:45 AM Ben Gidley <ben@gidley.co.uk> wrote: >> >>> I'd like to ask if you've considered how this proposal effects MPEG-DASH >>> players using Media Source Extensions? >>> >>> I've been using DASH players and they generally all break with today's >>> behavior on Chrome/Firefox is you're using a HTTPS page with a HTTP CDN for >>> the video content. This is because they mostly fetch content via XHR for >>> processing in their media source extension. >>> >>> It's not very desirable to push all video over SSL (as it breaks in >>> network caching commonly deployed by Telco's/ISP's) - is it possible to >>> consider a scheme to allow a media source extension to tech video? >>> >>> >>> >>> -- >>> Ben Gidley >>> >>> www.gidley.co.uk >>> ben@gidley.co.uk >>> >> > -- Ben Gidley ben@gidley.co.uk
Received on Wednesday, 22 July 2015 08:23:24 UTC