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

Summary:

   - There are user agent implementations that require per-site user
   permission and other DRM implementations for which such permissions and/or
   HTTPS should be required. Netflix (along with other content providers)
   currently supports both and will presumably continue to do so.
   - It is counterproductive to pretend that such implementations do not
   exist or that content providers will simply choose not to support them.
   - It is counterproductive to focus on solutions that fragment the web
   platform, especially in ways that discourage implementations from
   mitigating privacy and security concerns.
   - Mark's statements underscore the need for a consistent requirement
   rather than one based on evaluation of the properties of specific
   implementations, something subject to negotiation or coercion.
   - There is a concrete proposal [1] for solving the technical blocker
   that HTTP streams cannot be used (per the Mixed Content spec) with MSE on
   an HTTPS page.
   - It is reasonable 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.
   - Whether and how implementations report Mixed Content is up to the
   implementors, subject to change, and not something we can dictate or assume
   in this group or specification.
   - The only proposed solution that does not fragment the platform, does
   not discourage such privacy and security mitigations, and allows
   implementors to use appropriate mitigations for non-benign DRM
   implementations is to require that EME only be used from secure origins.
   - If this bug is not addressed, the WG is likely to receive an objection
   during the TAG’s review of the CR [8], if not sooner. The TAG has already
   expressed concern in its previous spec review [9].


On Tue, Mar 10, 2015 at 6:12 PM, Mark Watson <watsonm@netflix.com> wrote:

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

I understand from your reply (and your statements below) that you are in
favor of not using HTTPS for any CDMs.

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

Correct - this is an implementation decision and out of scope for EME and
this list. We cannot specify or assume such behavior. We should return our
focus to addressing the risks our specification exposes.

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

CDMs are not "designed" to need per-site permissions. The need for
permissions is the result of properties of most existing DRM solutions.

Netflix *does* support a platform that requests per-site permission as well
as others that really should, especially if used on an insecure origin.
There are certainly CDMs that justifiably do not require permission, but
that does not mean that Netflix or anyone else will _only_ support those.
It is counterproductive to pretend that all CDMs [Netflix will support] are
benign. Saying you won't support clients that need permissions or that
require HTTPS is also counterproductive and potentially harmful to users
(i.e. by discouraging implementors from doing what they think is
appropriate for their users).

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

Those statements were in reference to, among other things, the myth that
CDMs will be so benign as to not pose security or privacy concerns. This
thread is about mitigating the impact of requiring HTTPS, not whether HTTPS
should be required, which has already been discussed at length in the bug.

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

Just because you do not like the UX of some implementations does not mean
the solution is not viable. So far, the other proposed solutions are to a)
not require HTTPS ever, b) assume CDMs are benign, or c) fragment the web
platform, all of which are unacceptable.

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

This is just another way to fragment the platform, especially since you
have said that Netflix would not support sites that use HTTPS or require
per-site permissions. This is actually worse than the status quo because it
would punish implementors for using per-site user permissions - even if
they think it is appropriate - or discourage them from doing so (to avoid
requiring HTTPS, which you say Netflix will not support).

I suspect that whether to use per-site user permissions is even more
controversial than whether to require HTTPS, so tying the latter to the
former just complicates this issue. There are many implementations (mostly
CE devices but likely some browsers) that should have such permissions but
do not. Prompts are one of the mitigations to not having HTTPS, and
requiring HTTPS in the spec is a mitigation for implementations that choose
not to implement per-site permissions.

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

"Suffering ​UX degradation through warnings" is a bit melodramatic. What
warnings are you referring to? EME aside, I'm having trouble understanding
how the change in an icon outweighs the well-documented user benefits of
HTTPS.

Such concerns are probably moot as browsers move to change the UX for HTTP.
[7]

> …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
>>
>
[7]
http://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
[8] https://lists.w3.org/Archives/Public/www-tag/2015Feb/0045.html
[9]
https://github.com/w3ctag/spec-reviews/blob/master/2014/10/eme.md#user-facing-concerns


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