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

From: David Dorwin <ddorwin@google.com<mailto:ddorwin@google.com>>
Date: Friday, March 13, 2015 at 2:32 PM
To: Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>>
Cc: "<public-html-media@w3. org>" <public-html-media@w3.org<mailto:public-html-media@w3.org>>, "Jerry Smith (WINDOWS)" <jdsmith@microsoft.com<mailto:jdsmith@microsoft.com>>, Henri Sivonen <hsivonen@hsivonen.fi<mailto: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<mailto:public-html-media@w3.org>>
Resent-Date: Friday, March 13, 2015 at 2:32 PM

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

The bug seeks to remedy exposing "a permanent unique identifier in the client". As proposed in [10],  normative CDM requirements could protect such identifiers. [11] seems to accept this but notes that such a solution might be difficult to specify and cannot adequately address privacy concerns. Given the lack of consensus on requiring HTTPS for EME and user experience concerns associated with [1], the TF should: 1) attempt to specify normative language regarding CDM protection of sensitive and
2) enumerate why privacy would be worse than HTTP content delivery done today and attempt to address those issues before concluding [1] is the only solution.


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


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


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


On Tue, Mar 3, 2015 at 4:53 PM, David Dorwin <ddorwin@google.com<mailto: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

[10] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c83

[11] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c85




On Fri, Oct 24, 2014 at 9:53 AM, David Dorwin <ddorwin@google.com<mailto: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.
     *   See http://lists.w3.org/Archives/Public/www-tag/2014Oct/0100.html.

     *   There might be some sort of timeline / phased-in transition.
        *   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.
     *   Non-secure XHR responses passed to MSE would temporarily be considered Optionally-blockable Content like normal video.src content.
     *   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.)
     *   We would need to consider the security implications.
     *   This exception would be eventually be phased out as in #1.
     *   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.
     *   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