Re: Comments on the EME opinion

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

>
> 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,
http://blogs.msdn.com/b/playready4/archive/2011/10/10/ways-to-unqiuely-identify-a-silverlight-client.aspx
(especially Approach 5) might provide some insight into the risks on
desktop.