- From: Mark Watson <watsonm@netflix.com>
- Date: Fri, 24 Oct 2014 15:13:19 -0700
- To: Domenic Denicola <domenic@domenicdenicola.com>
- Cc: David Dorwin <ddorwin@google.com>, Henri Sivonen <hsivonen@hsivonen.fi>, www-tag <www-tag@w3.org>
> On Oct 24, 2014, at 2:34 PM, Domenic Denicola <domenic@domenicdenicola.com> wrote: > > From: David Dorwin [mailto:ddorwin@google.com] > >>> 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. > > Reading through Approach 5, it describes how to use of the PlayReady DRM client within Silverlight to obtain a unique client identifier, even when DRM is not actually needed: > >> Acquiring license is just a vehicle for getting the unique identifier which is embedded in the CustomData property of a license. Acquiring this dummy license is not dependent on user authentication status either. > >> It only relies on PlayReady license server which provides a consistent way of assigning a unique identifier for any PlayReady-enabled client. > > The thought of something like that, standardized into the (pluginless) web platform, is horrifying! Without user notification and/or permission requests, semi-permanent client IDs could be obtained on a large scale (i.e. all users of a particular browser). This ubercookie could be abused by ad networks, telecoms [1], governments (including our old favorite, the NSA), and more. Even a security/privacy-conscious user who disables plugins, etc. might not be aware of it. > > We should consider requiring or strongly recommending that user agents prompt or inform the user if an EME implementation brings along identifiers that cannot be cleared along with regular cookies and site data (similar to Mark’s “more privacy sensitive than regular cookies” bar). Ideally we would require that such identifiers be clearable along with cookies etc.---perhaps we should also strongly recommend that? Dominic, May I respectfully suggest that you and the TAG read the document, and especially the Privacy Considerations which I drafted quite some time ago and which address all of these issues. The question of whether some of the mitigations there should be normative certainly bears discussion. Also the extent to which W3C should recommend or require permissions dialogs - an aspect we understood to be important, but not in our scope. 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. ...Mark > > Has anyone tested current EME implementations in IE11 et al? Can anyone who buys a PlayReady server obtain an ubercookie? Can a coffeeshop attacker/ISP/government inject JS into insecure requests to video streaming sites in order to obtain ubercookies? > > [1]: https://news.ycombinator.com/item?id=8500131
Received on Friday, 24 October 2014 22:13:48 UTC