Re: Comments on the EME opinion

vOn Thu, Oct 23, 2014 at 3:26 AM, 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.

What's a logic leap? I tried to say that it seems that Googlers think
there exist EME-relevant DRMs for which it is not the case that the
identifiers are cookie-equivalent, but the Googlers don't specify
which DRMs and where. You seem to proceed to say:

> The concerns raised are based on our understanding of existing DRM
> implementations.

...without saying which DRMs.

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

Secure origins protect against a MITM injecting EME usage into
http-origin content. Mere eavesdropping could be addressed on the key
system level instead of (or in addition to) https. Secure origins do
not protect against the key system disclosing sensitive information to
the key server of an EME-using site that the user intentionally uses.

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

Is there public documentation explaining how this is accomplished?

> Even with the steps we have taken, we *still think* users should be informed
> and have control in some cases and platforms.

Which cases and platforms are these?

How does the prompting interact with JS execution? That is, do
synchronous EME calls get to finish and you prompt at the first
asynchronous point in the API? How does the site experience denial?

> In such cases, we use
> permissions, which we believe should be restricted to secure origins.

Yeah, per-site permissions for non-authenticated origins are pretty bogus.

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

Yeah. The notion that a lone UA vendor would restrict EME to https
when the competitors support services that refuse to deploy https
ignores the competitive dynamics that are relevant here. (Which is why
I don't particularly appreciate tweets like
https://twitter.com/sleevi_/status/526578372168519681 . I don't think
Mozilla has opposed to "strong privacy reqs" for EME. But not opposing
doesn't mean it would be a great idea for Mozilla to be eager to be
the first to ship with such restrictions in place. It's not cool to
suggest that we should restrict EME to https when Google has shipped
EME without such a restriction and enjoys the associated compatibility
benefits.)

If you a browser vendor is willing to ignore the competitive dynamics,
the vendor might as well take the position of not implementing EME.

On Thu, Oct 23, 2014 at 4:19 AM, Mark Watson <watsonm@netflix.com> wrote:
> 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.

I think it's important that users get security and privacy even when
they aren't competent to evaluate those aspects of a browser. It's not
cool if some browser gets more titles or higher resolution or bitrate
due to compromising on privacy or security but the users still "have
confidence" in the browser, because the users aren't well positioned
to evaluate the characteristics of the key system or the CDM. (This
problem is similar to Google apparently being shy to do with EME what
they did with Web Crypto: shipping with an https-only regardless of
what the spec says.)

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

In the case of EME, the competitive advantage available from ignoring
security and privacy considerations is rather unusual, because the
entities who want DRM to be used like DRM more the more deeply it's
baked into the browsing device (security) and seek to control how many
devices users use, etc. (privacy).

On Thu, Oct 23, 2014 at 11:43 PM, Domenic Denicola
<domenic@domenicdenicola.com> wrote:
>> Sure, that sort of trade make sense sense if you think DRM is a good thing like any other Web Platform feature that everyone should have, but if you don't, making that trade as a matter of principle (if *they* have it, *everyone* must have it, even if it's not a good thing to have) makes less sense.
>
> I don't really buy the idea that some web platform features are "bad" and thus should be confined to those that can pay for them. I'd rather make those web platform features better, which is indeed the purpose of this thread.

It's rather weird to first argue that DRM is bad for the Web and then
turn around and argue for things that would result in DRM being used
on the Web even more.

Anyway, the more important point I want to get across is this:

The principles of the Royalty-Free Web say that both of these should be true:
 1) Anyone can implement and ship a useful CDM (including codecs that
the relevant services want to use baked into the CDM) royalty-free by
writing code according to a public specification.
 2) Anyone can implement and operate a key server royalty-free by
writing code according to a public specification.

It is an error to think that if you accomplish #2 without
accomplishing #1, you've at least gone half-way making the Web better.
Having #2 without #1 has worse consequences to the health of the
ecosystem that having neither, because it makes things harder to
browser vendors who aren't Microsoft, Google or Apple.

If you solve #1 *first*, then it's time to consider solving #2.

On Fri, Oct 24, 2014 at 2:21 AM, David Dorwin <ddorwin@google.com> wrote:
> 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.

Thanks for finding and posting this. I'm not surprised that that's
possible. I am somewhat surprised that using PlayReady identifiers for
non-DRM purposes is outright suggested on MSDN, though.

It would be good if someone from Microsoft could comment if the
integration of PlayReady with EME mitigates the level of trackability
compared to PlayReady in Silverlight.

On Fri, Oct 24, 2014 at 12:31 PM, "Martin J. Dürst"
<duerst@it.aoyama.ac.jp> wrote:
> Just a (maybe stupid) question from a non-expert: When you speak about
> HTTPS, would that require transmitting all the content (huge video
> files,...) over HTTPS, or would that only/mainly apply to credential
> exchanges/signup/... or whatever it's called that goes on before the actual
> content is served?

The problem is that if EME is restricted to https, it means that XHR
on the same page can't fetch the video segments for MSE without
tripping over the mixed-content blocker (taken together with the
expense of serving the video segments over https).

The obvious question that is whether it would be feasible to do
something that'd make XHR from https to http not blocked. For example,
could streaming services deliver hashes of the video segments to the
JS app over https and could https to http XHR be unblocked if the JS
app told XHR the expected MIME type and hash and those matched what
XHR actually received?

On Sat, Oct 25, 2014 at 1:13 AM, Mark Watson <watsonm@netflix.com> wrote:
> But your tone suggests you think we have not even considered these
> things. We have, and the discussion would be more productive if
> comments were addressed to omissions, errors and suggestions for
> improvement on the work we have actually already done.

"What do actual UA+CDM combinations *do*?" is rather more relevant
than "Has this been considered?"

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

Received on Monday, 27 October 2014 11:03:21 UTC