Re: [EME] Mitigating the impact of HTTPS on content providers

On Wed, Mar 4, 2015 at 9:14 AM, Bob Lund <B.Lund@cablelabs.com> wrote:

>
>
>   From: Mark Watson <watsonm@netflix.com>
> Date: Wednesday, March 4, 2015 at 10:05 AM
> To: Bob Lund <b.lund@cablelabs.com>
> Cc: David Dorwin <ddorwin@google.com>, "<public-html-media@w3. org>" <
> public-html-media@w3.org>, "Jerry Smith (WINDOWS)" <jdsmith@microsoft.com>,
> Henri Sivonen <hsivonen@hsivonen.fi>
> Subject: Re: [EME] Mitigating the impact of HTTPS on content providers
>
>
>
> On Wed, Mar 4, 2015 at 8:33 AM, Bob Lund <B.Lund@cablelabs.com> wrote:
>
>>  As I understand the proposal, the response of fetches would be opaque
>> to JS. In the case of adaptive delivery protocols like DASH and HLS,
>> JavaScript needs to be able to parse responses to fetches of the manifest
>> file. Can [1] be extended to address this?
>>
>
>  ​You can always make a few requests over HTTPS for the stuff you need to
> parse in JS - that doesn't significantly impact capacity. Typically, you do
> not need to process the actual media requests.
>
>
>  So the response of fetch over https would not be opaque but the response
> of fetch would be opaque?
>

​An HTTPS page can make HTTPS requests using XHR or fetch() in the usual
way and can see the contents of the response as normal.​


>
>
>  The obvious concern with the proposal as it stands is that, IIUC, it
> would trigger mixed content warnings.
>
>
>  I thought the whole point of the proposal is that since the response of
> an MSE fetch over http is opaque, it would not trigger a mixed content
> warning.
>

​The proposal puts MSE on the same footing as img and @src on video. In
those cases the content is not visible to the page script and this proposal
provides the same kind of thing for MSE.​ Ryan says in [1]:

"Further, I'm not proposing that there be any special UI handling for these
mixed-content fetch()'s - that is, they behave as the user agent already
does when encountering passive mixed content (e.g. some form of UI
warning/degradation).
​"​

​The point is that the insecure transport for these request means the user
does not have the privacy and security guarantees that they would normally
expect of an HTTPS page: the HTTP requests are subject to snooping /
modification. The scope of the security concerns with respect to
modification of the payloads is greatly greatly reduced compared to the
case where the response contents are visible to JS, but still could be used
to launch attacks against the audio / video code in the browser, or simply
to replace the content with something else. For example [5] is still
possible.

In my opinion, for an interim option to be viable, we either need to not
give the user the expectation of HTTPS-level privacy / security in the
first place or we need to close the loopholes such that UAs do not feel the
need to present warnings to users.

…Mark

[5] http://www.ex-parrot.com/pete/upside-down-ternet.html​




>
>  …Mark​
>
>
>
>>
>>  Bob
>>
>>   From: David Dorwin <ddorwin@google.com>
>> Date: Tuesday, March 3, 2015 at 5:53 PM
>> To: "<public-html-media@w3. org>" <public-html-media@w3.org>
>> Cc: Mark Watson <watsonm@netflix.com>, "Jerry Smith (WINDOWS)" <
>> jdsmith@microsoft.com>, Henri Sivonen <hsivonen@hsivonen.fi>
>> Subject: Re: [EME] Mitigating the impact of HTTPS on content providers
>> Resent-From: "<public-html-media@w3. org>" <public-html-media@w3.org>
>> Resent-Date: Tuesday, March 3, 2015 at 5:54 PM
>>
>>    There is a proposal for a solution [1] to enable MSE buffers to be
>> treated as Optionally-blockable Content in Mixed Content scenarios in the
>> same way as standard src= sources. It would solve the general inconsistency
>> between these two types of sources of media data and removes one hurdle for
>> MSE-using sites to switch their pages, cookies, etc. to HTTPS. It also
>> addresses the short term impact to MSE-using content providers of requiring
>> secure origins to use the EME APIs [3].
>>
>>  For EME, the proposal has the same effect as idea #2 below but is much
>> more natural and does not requires any EME-specific changes. Note that it
>> involves Fetch instead of XHR
>>
>>  Feedback on the proposal has been minimal, mainly related to the
>> details of cookies, whether it weakens web platform security, and whether
>> it would address the EME issue. I expect that details will be worked out as
>> the proposal is formalized. If you have comments on the proposal, please
>> reply to the cross-posted proposal thread [1].
>>
>>  Since the blocking of HTTP requests for MSE was the main objection to
>> requiring secure origins for EME [3], I believe this gives us a path
>> forward on resolving that bug. This unblocks the completion of the
>> “powerful features” (formerly secure origin) algorithm step [4], but we
>> will need to decide how to document the relationship to the availability of
>> the Fetch and MSE functionality along with a maximum date for HTTP support.
>> That date would be similar to the flag day previously discussed but would
>> hopefully not impact user agents that implement the proposal [1], allowing
>> sites to switch to HTTPS sooner.
>>
>>  [1]
>> https://lists.w3.org/Archives/Public/public-html-media/2015Feb/0038.html
>> [2] http://www.w3.org/TR/mixed-content/#category-optionally-blockable
>> [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332
>> [4] https://w3c.github.io/encrypted-media/#requestMediaKeySystemAccess
>>
>>
>> On Fri, Oct 24, 2014 at 9:53 AM, David Dorwin <ddorwin@google.com> wrote:
>>
>>> The main objection to requiring secure origins for some or all key
>>> systems seems to be the impact this would have on content providers using
>>> MSE - mixed content restrictions would require them to also serve the
>>> encrypted media streams from a secure origin. While there is still some
>>> debate as to the actual impact, I'd like to start a brainstorm and
>>> discussion of ideas on how we might reduce the (immediate) impact on
>>> content providers while enabling user agents to require secure origins (in
>>> a reasonable timeframe).
>>>
>>>  Here are some ideas to start the brainstorming. (I don't necessarily
>>> support any of them at this point.)
>>>
>>>    1. Define a flag day by which HTTPS must be supported/required.
>>>       1. See
>>>       http://lists.w3.org/Archives/Public/www-tag/2014Oct/0100.html.
>>>       2. There might be some sort of timeline / phased-in transition.
>>>          1. For example, ramping up the amount of HTTPS traffic.
>>>        2. Temporarily allow Mixed Content XHRs to be provided to MSE
>>>    when EME is in use.
>>>       1. Non-secure XHR responses passed to MSE would temporarily be
>>>       considered Optionally-blockable Content like normal video.src content.
>>>       2. Given a choice, securing EME is probably more important than
>>>       preventing use of mixed content with MSE. (The alternative seems to be that
>>>       none of the bytes are secure.)
>>>       3. We would need to consider the security implications.
>>>       4. This exception would be eventually be phased out as in #1.
>>>       5. I'm not sure how practical this would be for implementions.
>>>    3. Establish an informal flag day, such as an agreement among major
>>>    browser vendors and/or content providers.
>>>       1. The goal would be to prevent content providers from segmenting
>>>       the platform by refusing to support user agents that choose to require
>>>       HTTPS. (See the second to last paragraph in
>>>       http://lists.w3.org/Archives/Public/www-tag/2014Oct/0096.html.)
>>>
>>>
>>>   David
>>>
>>
>>
>