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

On Fri, Mar 13, 2015 at 3:09 PM, Mark Watson <watsonm@netflix.com> wrote:

>
>
> On Fri, Mar 13, 2015 at 1: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].
>>
>> ​A number of the above points are way off the mark and / or way out of
> scope here. There's three things in particular I'd like to clear up:
>
> (1) To my knowledge there is only one, relatively low volume, platform
> where we (Netflix) accept a per-site EME-related permission dialog and this
> is for access to specific capabilities. EME is still available, without
> those capabilities, if the user declines. The scenarios where no
> permissions are required are - by deliberate design - the overwhelming
> majority. There are UX people here who do not really consider a permission
> dialog any different from the old Silverlight install prompt. Technically
> savvy people understand that these are very different things, but the
> large-scale impact on usage is similar. It is absolutely a central
> objective of the whole migration to EME / HTML5 (for us at least) to remove
> this or similar barriers between users and content.
>

I absolutely disagree with your characterization in the last sentence and
am quite concerned by it. The objective of EME is to bring protected
content into the web platform, including the privacy and security
properties it provides. Doing so also gives user agents control and options
that they did not have with plugins. The objective is absolutely not to
[force user agents to] hide the security and privacy implications of DRM
from users.

>
> It makes no sense to argue that just because some solutions requiring
> permissions exist, all solutions should suffer that or another disadvantage.
>

I was not arguing that all solutions should require permissions because
some solutions do. I was saying that an evaluation of the privacy and
security risks of some DRM implementations (that Netflix and others
support) would lead (some) reasonable people to say that a permission or
HTTPS should be required. It is not safe to assume that no permission
request implies no privacy or security risks. Perhaps influenced by your UX
people or others, some products have decided not to implement permissions.
However, that does not mean that this is the right thing to do or that we
should assume/force all other implementors to make the same decision.

>
> (2) The proposal [1] is very much broken. If there is to be an interim
> solution on the way to full HTTPS it must have the following properties:
> (a) It should improve the security and privacy properties of the site,
> compared to the status quo (HTTP), by securing the transport of all assets
> except the video assets
> (b) It should not suffer any UX degradation compared to the status quo
> (especially since it's an *improvement* (a))
>
> [1] does not have those properties: it makes the UX *worse* when the
> security properties are *better*. Sites should not have to pay with worse
> UX when they improve security. It does not solve anything at all.
>
> Most users who understand anything about secure websites see them in
> binary terms. Anything other than a clean green padlock (or whatever) with
> no warnings comes across as dangerous or broken (as, indeed, it should).
>
> Either the UX should match full HTTPS sites or it should match the status
> quo. I completely understand that the former involves finding a different
> way to secure the transport of the video assets. You and Ryan have said
> that is not feasible and I myself don't have many ideas for that. But I
> have not heard much about the latter.
>

The idea that the mixed content icon is worse than the HTTP icon is an
opinion. While some users may be concerned, others view partial encryption
as a good thing. The UI difference provides an accurate indication of the
state of the page. This is probably why you have not heard much about the
latter.

>
> (3) The prospect of UAs introducing new UX for HTTP sites [7] is likely
> irrelevant for this discussion as it operates on a completely different
> timescale. The proposal triggered quite some debate and I think it unlikely
> any UA would take this step until HTTPS becomes the norm. Indeed, doing so
> earlier, whilst most sites are still HTTP, would resulting in normalization
> of the new UX in the minds of users, defeating the object. If an interim
> solution for the mixed video content case is to be useful, it needs to be
> available much sooner.
>
>
> Below, you characterized the proposed solutions to this bug as: to a) not
> require HTTPS ever, b) assume CDMs are benign, or c) fragment the web
> platform.
>
> I have not proposed (a) or (b). I am not sure where those come from.
>

(a) is the status quo. Secure origins are not currently required, and
content providers - especially Netflix - will not support implementations
that require HTTPS. As a result, HTTPS is unlikely to be required by any
implementation. (Note: "ever" should have been "on any implementation" and
did not mean "ever" in the future.) You are actively supporting the status
quo and resisting attempts to change it.

"Benign" (b) was your word on March 9th ("our objective should be that the
security and privacy implications of using EME are so benign that no such
permission is needed"). You continue (above) to argue that implementations
should not need (or even if they do, should not use) permissions.

>
> I assume by "fragment the web platform" you mean that, according to my
> proposal that the HTTPS requirement be dependent on CDM properties, there
> may be some platforms requiring HTTPS and others that do not and thus there
> may be sites that work on some platforms and not others. I would have
> thought that sufficient incentive for the CDM implementors to avoid those
> properties that lead to the HTTPS requirement and that this would generally
> be a good thing(™). Such fragmentation is a consequence of different
> properties / features in different CDMs. We are making good progress
> establishing a common set of baseline features which will enable
> interoperability, but I have no expectation that this will - or even should
> - mark an end to CDM-specific capabilities. CDMs will vary in the license
> properties they support, robustness properties associated with different
> kinds of content and other things. Nothing otherwise has been proposed or
> agreed here.
>

This doesn't address the fragmentation concern at all. You appear to
acknowledge that some CDMs will implement features that should require
HTTPS. At the very least, you've acknowledged that some implementations
require per site permission. But I see no solution for ensuring such
implementations are supported by Netflix and other content providers. There
is nothing technically wrong with such implementation that should exclude
their users from your service. As you noted, you already support one such
implementation.

It is misleading to say that "CDM implementors [could] avoid those
properties that lead to the HTTPS requirement." While I agree that this
would be a good thing, it is not practical - at least to a degree where
everyone would agree that there is no need for HTTPS or per site
permissions. As an example, most DRM implementations rely on Distinctive
Identifiers (otherwise, they wouldn't be included in the spec). Many
content providers require them, especially for higher value content. It is
reasonable for an implementor to take the position that this is a risk to
their users and they would like to a) ask the user's permission and b) have
some certainty about the origin that is requesting the identifier (thus
requiring HTTPS). Other implementors may make different decisions, but
arguing that "CDM implementors [could] avoid those properties that lead to
the HTTPS requirement" is not grounded in reality. Even if a DRM
implementation followed all the recommendations currently in the spec (I'm
fairly confident most implementations do not), it would still be reasonable
for a UA implementor to require user permission or HTTPS. That is the UA
implementor's decision.

>
>
> Finally, the very beginning of this thread included some suggestions
> around industry coordination on a reasonable timescale for migration to
> HTTPS. I did and still do think that might be a productive discussion, but
> I'm not aware of anyone taking the initiative to start such an
> industry-wide dialog.
>

That could be a productive discussion, and I even mentioned a date again in
my March 3rd email. [1] is part of the solution for an industry-wide
migration path.

No one is stopping you from "taking the initiative to start such an
industry-wide dialog." Instead, you and others have spent most of this
thread, which was intended to start a dialog, and the bug arguing that
HTTPS is not necessary. I'm confused why you are interested in a timescale
if you do not believe HTTPS is necessary. Also, since you refuse to
consider the Mixed Content solution, it's reasonable to assume that the
discussion would boil down to sometime after Netflix is ready to fully
support HTTPS. That's more of a one-way conversation than an industry-wide
dialog. I’d be happy to discuss dates and other details if there was reason
to believe that another outcome was possible.

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