[Bug 20965] EME results in a loss of control over security and privacy.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20965

--- Comment #15 from Mark Watson <watsonm@netflix.com> ---
First, I think it's clear that the UA needs to know the privacy properties of
the CDM so that appropriate controls can be offered to the user (authorization,
clearing of stored data etc.). This would immediately be an improvement over
plugins. Again, I expect UA implementors will choose which CDMs they integrate
with, rather than providing an open 'CDM plugin' API.

Regarding unique identifiers, hopefully the Privacy Interest Group can help us
here. Identifiers that are not 'unique' may still have privacy/tracking
implications (cf ZIP codes). I'm not sure the appropriate term for 'identifiers
with privacy implications', so I'll just use 'identifier' in the following.

I see four separate privacy/tracking issues with identifiers:
1) The initial message (or part of it) for a dummy file may effectively form an
identifier that any site* could use for tracking over time
2) The initial message (or part of it) for a dummy file may effectively form an
identifier that any site* could use for tracking across sites, if those sites
collaborate
3) An identifier available to the server side of the keysystem may be used for
tracking over time by a single site
4) An identifier available to the server side of the keysystem may be used for
tracking across sites, if those sites collaborate

* including sites which do not support the server side of any keysystem

Tracking across sites (2, 4) can be addressed if the identifier is
origin-specific i.e. if netflix.com sees a different identifier to hulu.com.

Tracking by arbitrary sites (1, 2) can be addressed if the initial message is
not consistent. For example if it is encrypted with a keysystem public key, and
contains information which changes every time a message is generated (salt,
nonce, timestamp) etc.

That leaves (3), where the considerations are very different depending on
whether the UA can cause the identifier to be reset. If it can, then the
situation is hardly different from cookies today. Indeed UAs may reset such
identifiers whenever the user clears cookies. If it can't, then user
authorization as described by Henri may be appropriate.

Whatever the situation, the UA implementor needs to know it and to provide
information and control to the user. I don't think we should be prescriptive in
the specification either about what CDMs might do. Certain sites may not
operate without certain kinds of identifier and users should be able to make
informed choices about whether to use those sites, rather that the W3C
attempting to proscribe them (though I do understand the difference between
'offering users information and the chance to make a choice' and 'informed
choice').

I also don't think we should prescribe what UAs should do (W3C specifications
don't generally mandate specific privacy dialogs etc.).

However we should describe the issues and make it clear that the UA implementor
MUST have complete knowledge of the CDM privacy properties so that they can
provide appropriate protections.

Regarding persistently stored information, there is one use-case in the
specification: secure proof of key release. This requires the CDM to
persistently store session identifiers - but not the licenses or keys - for
MediaKeySessions that previously existed, until receipt of the key release
information by the server is acknowledged. This is origin-specific and so only
allows a given origin to re-discover session identifiers for sessions with that
same origin. So, they provide the possibility to reintroduce device tracking if
it's not already present - if the session identifiers have appropriate
uniqueness properties.

Again, the UA integrating with a CDM needs to know the privacy properties of
the identifiers to provide appropriate choices and protections to the user.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 22 February 2013 16:37:24 UTC