W3C home > Mailing lists > Public > www-tag@w3.org > October 2014

Re: Comments on the EME opinion

From: David Dorwin <ddorwin@google.com>
Date: Wed, 22 Oct 2014 17:26:58 -0700
Message-ID: <CAHD2rsg14mT9T_oY59QPBpYm-yuM=Yw9ZgPb47wa8xxuDj0TgQ@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: Henri Sivonen <hsivonen@hsivonen.fi>, Domenic Denicola <domenic@domenicdenicola.com>, www-tag <www-tag@w3.org>
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.

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

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.

> ​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. Regardless, if a UA vendor
made that decision, would Netflix support HTTPS for that UA? 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.

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

> ...Mark
>> --
>> Henri Sivonen
>> hsivonen@hsivonen.fi
>> https://hsivonen.fi/
Received on Thursday, 23 October 2014 00:27:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:06 UTC