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

Re: Comments on the EME opinion

From: David Dorwin <ddorwin@google.com>
Date: Thu, 23 Oct 2014 16:21:12 -0700
Message-ID: <CAHD2rsiJTu2pGCY-i05CE=CfjT431e6KV8_KLNpT3tCnEYysZQ@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 Thu, Oct 23, 2014 at 1:48 PM, Mark Watson <watsonm@netflix.com> wrote:

> 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:
>>>>  <snip>

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

Based on the OS requirements for IE11 (Windows 8.1) and Safari (OS X
Yosemite), it is reasonable to assume that at least part of the CDM
functionality is implemented in the OS, possibly running privileged. If
that is the case, that is certainly a distinction, especially if the
browser employs sandboxing.

You've focused on a few desktop browsers. As with other areas of API
design, it's important to consider a broad range of devices, especially
mobile. Mobile devices almost always use platform-based DRM implementations
that use hardware-based IDs. (The same may be true of some desktop
implementations too.) That is a large distinction vs. the rest of the user

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

That is a poor choice to give user agent implementors.

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

This isn't a "dumb thing" - it is caused by the design of the spec.

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

The lack of permissions or prompts does not necessarily equate to "no
greater security or privacy risk ​than unprotected content." It's quite
possible that there is a greater risk and users would benefit from prompts.
For example, Chrome does prompt on some platforms.

While not specifically about an EME CDM implementation,
(especially Approach 5) might provide some insight into the risks on
Received on Thursday, 23 October 2014 23:21:59 UTC

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