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

On Mon, Mar 9, 2015 at 8:47 AM, Mark Watson <watsonm@netflix.com> wrote:

>
>
> On Tue, Mar 3, 2015 at 4:53 PM, David Dorwin <ddorwin@google.com> wrote:
>
>> 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].
>>
>
> ​As you noted above, that proposal is at an early stage, with very little
> feedback.
>

I did not say it was at an early stage. I only said there are some details
to be worked out.


> So, I don't think we can assume it solves any problems just yet. If I
> understand correctly, it would trigger mixed content warnings in some
> browsers and this would not be an acceptable UX for any
> ​professional commercial
>  service. That's not to say it's not on a good path, only that it is not
> there yet.
>

As Ryan noted [5], it is "unwise to impossible to meaningfully address the
privacy concerns" of using mixed content. I think it's safe to assume there
are no options that would permit HTTP streams in an HTTPS page in a way
that browsers would not consider Mixed Content.

That would mean the only options without such UX would be to use HTTPS for
streams or not use HTTPS at all for any CDMs. Which are you proposing?

>
> ​Even if that proposal were to solve the cost / capacity problems,
> requiring HTTPS for EME has to be justified on some technical basis. In the
> case where the strongest security and privacy approaches we have discussed
> are implemented, there is no such justification.
> ​Certainly,
>  in cases where some kind of permanent identifier is to be provided
> ​ and,
> as a consequence of that
> ​,​
> user permission is needed
> ​, then​
> we need to learn to whom the user is giving permission
> ​. However​
> - as I have said before - our objective should be that the security and
> privacy implications of using EME are so benign that no such permission is
> needed.
>

It is counterproductive - and sets the discussion back eight months - to
dredge up old excuses that have already been addressed in the bug. There is
no evidence that most CDMs will be so benign, and there have been no
proposals for normative text to define when HTTP would be acceptable. Even
such text is likely insufficient due to the potential for platform
fragmentation/exclusion, which you spelled out [6] .

Given that, we should move forward with the only normative solution that
addresses these problems, especially now that we have a solution to the
technical problem of enabling MSE with Mixed Content streams.

>
>
>>
>> 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.
>>
>
> I don't agree that we have a complete solution just yet. We could
> certainly flesh out that section with some conditions in which HTTPS is
> clearly required but I don't see the argument for it being always required.
>

Short of hiding the privacy risks of Mixed Content, what is your definition
of a complete solution?

>
>
> ​…Mark​
>
>
>
>>
>> [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
>>
>
[5] https://lists.w3.org/Archives/Public/public-html-media/2015Mar/0013.html
[6] https://lists.w3.org/Archives/Public/www-tag/2014Oct/0096.html


>
>>
>> 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
>>>
>>
>>
>