- From: <bugzilla@jessica.w3.org>
- Date: Tue, 22 Jul 2014 15:41:22 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332
Mark Watson <watsonm@netflix.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |watsonm@netflix.com
--- Comment #6 from Mark Watson <watsonm@netflix.com> ---
(In reply to Ryan Sleevi from comment #1)
> 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.
>
No. As described in the Security and Privacy considerations and at great length
elsewhere, UA implementors are expected to be aware of the properties of the
CDMs with which they integrate and treat them appropriately. This is not a
plugin API where you have no knowledge of the properties of the plugin.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 22 July 2014 15:41:24 UTC