Re: [mixed-content] DASH Players and Mixed Content

I want to clarify that the proposal ([1] along with updates such as [2]) is
intended only as a temporary solution, a potential bridge, until CDN
traffic can be moved to TLS. It would bring MSE-based streams to parity
with .src= streams. (Note: This is only relevant as long as user agents
continue to allow mixed video and audio loaded via <video> and <audio>,
which are two of the few categories of content that are
optionally-blockable [3].) In-band data should not be exposed from Mixed
Content streams today (in the .src= case), and this proposal would not
change that. As Anne notes [4], exposing such contents would make the
existing hole bigger.

Regardless of whether Mixed Content MSE streams are enabled (i.e. [1]),
accessing BMFF boxes or in-band data requires an unmixed scenario - either
a) an insecure page or b) using secure channels for all content. (a) is
going to become increasingly restricted as more new and existing APIs
require secure contexts [5][6][7]. For example, support for insecure
contexts is already deprecated in EME [8][9]. In addition, there is a
movement towards changing the UX for insecure pages (e.g. [10]).

I urge content providers that *would* use Mixed Content MSE with opaque
streams (with the discussed limitations), to speak up here and in the MSE
spec issue [11]. There was no such interest expressed by content providers
when the proposal was made, leading to questions about whether it was worth
pursuing, and now the MSE editors are debating whether to punt Mixed
Content support to a future MSE version [11], which would likely be too
late to be useful. Therefore, such input is important if you would like to
see the proposal standardized and implemented. Now is also a good time to
start planning for use of secure channels for all content, which is the
real long-term solution.


It's not very desirable to push all video over SSL (as it breaks in network
> caching commonly deployed by Telco's/ISP's)...

This is actually an advantage of using TLS for some content providers for
whom such caching is undesirable.

[1] https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0371.html
[2] https://lists.w3.org/Archives/Public/public-html-media/2015Apr/0013.html
[3] http://www.w3.org/TR/mixed-content/#category-optionally-blockable
[4] https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0132.html
[5] https://w3c.github.io/webappsec-secure-contexts/
[6]
https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins
[7]
https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
[8] https://w3c.github.io/encrypted-media/#requestMediaKeySystemAccess
[9]
https://w3c.github.io/encrypted-media/#are-insecure-contexts-allowed---deprecated
[10]
https://sites.google.com/a/chromium.org/dev/Home/chromium-security/marking-http-as-non-secure
[11] https://github.com/w3c/media-source/issues/22


On Fri, Sep 18, 2015 at 12:05 AM, Mike West <mkwst@google.com> wrote:

> +Ryan and David, who might have informed opinions about Will's feedback. :)
>
> -mike
>
> --
> Mike West <mkwst@google.com>, @mikewest
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München,
> Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
> Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
> Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>
> On Thu, Sep 17, 2015 at 10:42 PM, Nottingham, Mark <mnotting@akamai.com>
> wrote:
>
>> Hey,
>>
>> Sorry for the delay, but some feedback forwarded from one of our DASH
>> folks:
>>
>> Regarding this statement,
>>
>> > The "opaque" response prevents direct access to the Response data.
>> Similarly, the SourceBuffer object does not allow direct access to the data
>> - this is only passed on to the audio/video decoders, same as the existing
>> <audio>/<video>/<source> tags today. I realize this may prevent access to
>> the full capabilities of MSE; indeed, some use cases require access to the
>> content in order to do adaptive streaming.
>>
>> The "some use cases" turn out to be the majority of future anticipated
>> live service streaming. The DASH-AVC/264 Interop Guidelines v3.0 <
>> http://dashif.org/wp-content/uploads/2015/04/DASH-IF-IOP-v3.0.pdf> split
>> live services in to two major groups; those which rely on MPD update only,
>> and those which rely on MPD updater and the ability to parse segments to
>> retrieve both inband events and timestamp information.
>>
>> 1. There are in-stream event messages are carried in there 'emsg' box of
>> the ISOBMFF container. MSE-based players must parse the XHR response and
>> extract these messages prior to appending the data to the source buffer.
>> These messages are used to convey triggers for ad ­insertion, manifest
>> refresh, stream associated metadata such as sports scores etc.
>>
>> 2. SegmentTimeline mode of live operation can be conducted in such a
>> manner that the address of the the next segment is constructed by parsing
>> the tdft timestamp of the latest segment described in the manifest. This is
>> an efficient mode of live stream operation, as the client only needs to
>> download the manifest once (until signaled to refresh it for ad insertion
>> or EOS)
>>
>> If the proposal is implemented then a live service which is targeting a
>> mixture of MSE and non-MSE clients would be forced to comply with the
>> lowest common denominator (MSE with opaque response data) and would be
>> unable to use inband events. Since the majority of future distributions are
>> likely to involve MSE clients, this proposal effectively limits live DASH
>> deployments to their simplest mode of operation and negates a body of
>> features based on inband event signalling.
>>
>> Hope this helps,
>>
>>
>> > On 21 Jul 2015, at 12: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
>>
>> --
>> Mark Nottingham    mnot@akamai.com   https://www.mnot.net/
>>
>>
>