Re: Comments on the EME opinion

On Thu, Oct 23, 2014 at 12:57 PM, David Dorwin <ddorwin@google.com> wrote:

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

​As suggested elsewhere, it might well be productive for us to work on
normative requirements that would need to be met on HTTP origins. I do
think we need to go through the issues rigorously, as Henri did.​


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

​That's dependent on the implementation approach. For IE, Chrome and
Safari, I don't see how you make much of a distinction between user agent
code and CDM code: it's all code written by and owned by the same
organization. I do see that in Chrome's case the CDM code hasn't had the
advantage of public review that ​most of the rest of Chrome has (although
that is your decision, to be fair).

But, again, if for some reason the UA implementor does not have knowledge
of the CDM properties, then I can see how you might judge that a
restriction to HTTPS origins is prudent. In the end it's a balance between
the risks associated with an HTTP origin and the benefits of having users
use fewer plugins.


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

​I don't think we can take on responsibility in our specification for every
possible dumb thing that someone could do with a Chromium fork. ​There's a
lot more - outside of EME - that we'd need to consider if that was our
objectives.


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

​As far as I know our HTML5 player does not encounter permissions in
Chrome, IE and Safari desktop today. We went to some lengths to redesign
various requirements to ​achieve that.

...Mark


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