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

On Tue, Mar 10, 2015 at 5:52 PM, David Dorwin <ddorwin@google.com> wrote:

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

​It's not me who is proposing options. Browsers offer a number of tools to
site developers. This was a proposal for a new tool, which I have noted has
a disadvantage large enough that we would not use it for our service.

As a non-UA-implementor, I see two broad options for addressing the problem
with the new proposal. The first would be to address the privacy / security
concerns somehow (which you and Ryan are saying is not an option). The
second would be not to set the user expectations of privacy / security in
the first place (but still to provide those properties at least insofar as
it is possible with the HTTPS/HTTP mix). Maybe the latter is also not an
option for some other reasons, but that's up to UA implementors.


>
>> ​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] .
>

​My suggestion would be that HTTP should be allowed for those CDMs that do
not need per-site user permission. If a CDM was designed such that it
*does* need per-site permission, that would be a major issue for us - we
probably would not use it - so I'm confident there will be (indeed are)
CDMs that do not require that.

The financial implications of migrating immediately to HTTPS for content
did not change overnight - though we are working on optimizations that
would mitigate that impact - so I am not sure what you mean by "old
excuses" or "setting the discussion back".


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

Except that it's not the only solution and we do not have a viable solution
​to the technical problem of enabling MSE with Mixed Content streams.

I'm happy to draft the normative text tying the HTTPS requirement to the
need for per-site user permission. It makes sense to me to extend it to
cases where certain kinds of persistent identifiers are present (though we
may already have normatively prohibited all those, I need to check).


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

​A solution which allowed users to enjoy the privacy and security benefits
that come from the "mixed" HTTPS/HTTP approach without suffering ​UX
degradation through warnings, where both "benefits" and "UX degradation"
are relative to the existing HTTP solution.

…Mark



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