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

On Fri, Mar 13, 2015 at 2:32 PM, David Dorwin <ddorwin@google.com> wrote:

> 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].
>
>  I disagree with a number of premises cited above. I also disagree with
the conclusion. Finally, the opinion of the TAG should be of no concern on
this matter, given the opinion of the TAG is just one data point, and given
the paucity of expertise and review that occurred on this subject, should
be discounted.


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