Re: Comments on the EME opinion

On Wed, Oct 22, 2014 at 6:19 PM, Mark Watson <watsonm@netflix.com> wrote:

>
>
> On Wed, Oct 22, 2014 at 5:26 PM, David Dorwin <ddorwin@google.com> wrote:
>
>>
>> On Wed, Oct 22, 2014 at 9:25 AM, Mark Watson <watsonm@netflix.com> wrote:
>>
>>>
>>>
>>> On Wed, Oct 22, 2014 at 12:17 AM, Henri Sivonen <hsivonen@hsivonen.fi>
>>> wrote:
>>>
>>>> On Sat, Oct 18, 2014 at 12:23 AM, Mark Watson <watsonm@netflix.com>
>>>> wrote:
>>>> > On Fri, Oct 17, 2014 at 2:08 PM, Domenic Denicola
>>>> > <domenic@domenicdenicola.com> wrote:
>>>> >> Finally there's the aspect that the TAG would prefer any
>>>> privacy-sensitive
>>>> >> features (of which EME is one, I believe) to be restricted to secure
>>>> >> origins. Search for "RESOLUTION: We support..." in
>>>> >>
>>>> https://github.com/w3ctag/meetings/blob/gh-pages/2014/sept29-oct1/09-29-f2f-minutes.md
>>>> .
>>>> >
>>>> > In practice there's no reason for EME in browsers to be any more
>>>> privacy
>>>> > sensitive than regular cookies.
>>>>
>>>> I agree that that's true in *principle*. However, as far as *practice*
>>>> goes, is any browser other than Firefox known to have made or be on
>>>> track making it true in *practice*? I don't recall any browser vendor
>>>> other than Mozilla having made public statements about endeavors to
>>>> make it so. OTOH, the concerns Googlers raised in
>>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332 strongly suggest
>>>> that they have a concrete reason (that they don't name) to be worried
>>>> about it not being true for some key system / CDM.
>>>>
>>>
>> That's quite a leap in logic. I'm disappointed that you interpret our
>> efforts to champion user security and privacy as having a surreptitious
>> motive. On this issue, we are actually more concerned for users of other
>> user agents.
>>
>> The concerns raised are based on our understanding of existing DRM
>> implementations. One of our goals is to minimize the risk to user security
>> and privacy should user agents expose such implementations to the web or
>> otherwise fail to provide appropriate privacy and security protections for
>> users. Requiring secure origins at least mitigates the danger for users of
>> such user agents.
>>
>
> ​That's a very odd statement: because you don't have confidence that some
> *other* user agents will adequately address ​the security and privacy
> issues you would like W3C to impose a solution of your choice, for the
> benefit of users. Honestly, it is not important whether Google has
> confidence in other user agents. What's important is whether *users* of
> those user agents have confidence in them: a decision they make every time
> they choose which UA to launch.
>

That's not what I said. I described what I believe are likely outcomes with
the current spec. (See below for more context.) As a spec editor, I would
like to avoid those.
Also, the W3C and TAG are taking stronger positions towards protecting
users *by default*.


>
> All our specifications have Security and Privacy considerations (and
> should have), but I have never seen a section for mandatory measures to
> guard against implementors who ignore the Security and Privacy
> considerations.
>

I think it's pretty clear that EME has properties that most/all other specs
do not have.

The secure origin requirement does not guard against implementors that
ignore the considerations. It provides a normative mitigation of security
and privacy issues that are not currently otherwise normatively addressed
because the robustness mechanisms and other parts of the CDM are outside
the scope of the spec. We know HTTPS will mitigate a lot of issues and that
all user agents can enforce it regardless of the CDM implementation. There
may be other mitigations, but there are currently no such normative
requirements.

For most APIs, these security and privacy considerations would likely be
addressed in the user agent code, but that's not possible with EME where
much of the implementation is outside the user agent and dependent on the
platform, agreements, etc. HTTPS is one of the few mitigations that can be
implemented entirely in the user agent.

It’s important to recognize that the set of implementors is much larger
than major browser vendors like Google and Mozilla (both of which are
trying hard to address these issues). There is a long tail of forks of
WebKit, Chromium, etc.  For most APIs, the major vendors would implement
the considerations in the mainline user agent source code, but for EME,
every fork is responsible for security and privacy on every platform they
integrate with. Do you believe the person integrating such a fork onto a TV
in time for the holiday season is going to read the security and privacy
considerations sections, check with the DRM vendor, implement mitigations,
etc.?


>
>> As for what we can directly control, Chrome and Widevine have worked
>> together to develop and ship solutions that provide users a more secure and
>> privacy-sensitive way to experience protected content on a variety of
>> platforms.
>>
>> Even with the steps we have taken, we *still think* users should be
>> informed and have control in some cases and platforms. In such cases, we
>> use permissions, which we believe should be restricted to secure origins.
>>
>
> ​And yet, I am still hopeful that "in some cases and on some platforms"
> EME will enable users to view protected content with no greater security or
> privacy risk ​than unprotected content that does not use EME. This is the
> goal, no ? In such a case there is no need for permissions.
>

That would be great. How many such platform exist today? The reality is
that content providers, including Netflix, make reducing the risks very
difficult.

Even though the risks can be reduced, “no greater security or privacy risk”
is likely impossible as long as there are robustness requirements.

I think this decision should be based on the current reality, not some
ideal that we hope for but may never come. If those goals become reality,
we can reconsider the requirement for a secure origin. We could even
consider normative exceptions like “no greater security or privacy risk” as
long as we are clear what that means.


>
>>> ​Google, and other UA vendors, will have to speak for themselves. But my
>>> point was that the UA should know whether the CDM exposes identifiers in a
>>> way that raises any greater privacy concern than regular cookies. If it
>>> does raise such concerns - or it for some reason they don't know - then the
>>> UA implementor might take the view that the use of that CDM should be
>>> restricted to HTTPS​. If not, why should they be required to restrict it ?
>>>
>>
>> That's different than the statement you made.
>>
> ​
>  Yes, but not incompatible.​
>
>
>> Regardless, if a UA vendor made that decision, would Netflix support
>> HTTPS for that UA?
>>
>
> ​It's a UA/CDM combination and probably not in the short term, though we'd
> evaluate on cost vs market share grounds if/when we came to it.​ What we're
> hoping is that every UA will support at least one CDM that does not need to
> be restricted to HTTPS.
>

Assuming you are not referring to Clear Key, this seems very unlikely. I
would argue this is not possible for any UA relying on an existing
platform-based DRM implementation. Given the resistance from some DRM
providers to other changes for EME, I'm not confident that this will change
soon.

As an implementor that has done a lot of work to address these issues, I
may still like to use HTTPS to, for example, prevent network attackers from
abusing persisted permissions. Unfortunately, that is not an option
implementors have.


> What about other content providers? If the answer to either question is
>> "no", then there isn't really a choice for UA vendors to do as you suggest.
>>
> Assuming this is the case, we need some type of forcing function.
>>
>
> ​You're saying that in practice UAs will have no choice but to allow HTTP.
> How is this an argument for forcing them to restrict to HTTPS ?
>

A secure origin requirement will force applications to support HTTPS, which
really should be required for some (most) implementations. I have
repeatedly asked for other suggestions in the bug, but none have been
offered.


> The forcing function here is that UAs will need to address the security /
> privacy issues so that they *can* allow HTTP. A good thing, no ?
>

See above for why I think this is unlikely. In the meantime, users are at
risk. A bad thing, no?


>> I believe that a majority of implementations (considering devices, TVs,
>> etc. as well as desktop browsers), at least in the near term, are likely to
>> raise “greater privacy concern than regular cookies”, so even with your
>> test, *most* user agents should require HTTPS. Even those that mitigate the
>> privacy issues might still require a secure origin to mitigate security
>> risks.
>>
>
> ​So, when you are talking about devices you are in a whole different world
> where on the one hand HTTPS has any number of additional problems (trust
> stores, clocks ...) and on the other hand there are other solutions
> available.
>

I assume you are referring to something like
https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.html.
That hardly seems like a better solution than HTTPS - as I understand it,
the solution involves the permanent hardware identifiers we are trying to
avoid here. If anything, the origin should probably be securely verified
(i.e. HTTPS) before the user agent provides access. Also, this further
segments the platform, which is harmful to the web.

...Mark​
>
>
>
>>
>>
>>> ...Mark
>>>
>>>
>>>
>>>
>>>>
>>>> --
>>>> Henri Sivonen
>>>> hsivonen@hsivonen.fi
>>>> https://hsivonen.fi/
>>>>
>>>
>>>
>>
>