- From: <bugzilla@jessica.w3.org>
- Date: Mon, 14 Jul 2014 23:03:36 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332 Ryan Sleevi <sleevi@google.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sleevi@google.com --- Comment #1 from Ryan Sleevi <sleevi@google.com> --- I don't see how #2/#3 can be sanely/reliably implemented by a UA, given that EME makes it clear that the Key System is "opaque". Bug 20944 captures some of this discussion, as noted, but even the Key System name itself is opaque (in as much as there is no registry). I do agree that it seems impossible to prevent EME from disclosing some degree of identifying information. At a minimum, you're guaranteed a single-bit of user-state (authorized vs not-authorized), but you're potentially looking at degrees ranging from classes-of-devices to per-user identifiers. >From a UA perspective, it seems like a design goal of EME to keep the UA opaque as to the nature of the CDMs key system, which means that the effective security/privacy of any given CDM is the 'worst possible' of all CDMs. Since the UA has to treat the CDM as a blackbox (again, per the discussions of Bug 20944; if this was not the case, we'd be normatively specifying how key systems behave and what information they're given access to), it seems like you must always assume the CDM has user-and-hardware uniquely-identifying data. Put differently, if a UA wanted to implement #2/#3, it'd need to know what key systems may be supported, and whether the privacy concerns for that key system align with the UAs or W3C's views on privacy protection. A UA implemented atop a generic API (for example, Microsoft's Media Foundation APIs, http://msdn.microsoft.com/en-us/library/windows/apps/dn466732.aspx ) would need to implement some form of whitelisting, except it's unknown/undocumented what values of key systems are acceptable (no registry). Further, it'd require the UA to know how the key system was implemented, in order to evaluate how that key system adheres to protecting user identifiers in transit. For some UAs, it'd also require the public to be able to know how the key system was implemented, in order that they can verify the claims of the CDM/UA vendors. If we had such a system where the key system was open/documented, rather than opaque, we presumably wouldn't need EME (Bug 20944). So it does seem that #1 is the only sane way to cut this knot, at least in a way that ensures the consistency for the greatest number of UAs. That said, it does require understanding a solid definition of secure origin. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 14 July 2014 23:03:37 UTC