Re: Comments on the EME opinion

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.

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.


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



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


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

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 ?


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

...Mark​



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