This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
As discussed in http://lists.w3.org/Archives/Public/www-tag/2014Oct/0106.html, some DRM implementations---for Silverlight, at least---bring along semi-permanent client IDs. It would be ideal if we required that clearing ones cookies, history, etc. also cleared any such identifiers. I am unsure this is possible for robustness reasons, and as such filed bug #27165 to explore mitigating strategies, but if there is even a chance of requiring they be clearable that would be much better, and would love to have that discussion in this bug.
For example, see also: http://www.w3.org/TR/IndexedDB/#privacy http://www.w3.org/TR/webstorage/#privacy
Mark to look into addressing the discussion at TPAC, including making part of the privacy and security sections normative (like webstorage) and adding a series of SHOULDs. Note that we are probably going to tackle identifiers in general here (i.e. no identifiers, clearable identifiers, per-origin identifiers).
In the F2F discussion it seems there is general agreement that unique identifiers should be clearable. There is already text in the Privacy section: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#privacy This is very similar (identical?) to text in Web Storage, for example: http://www.w3.org/TR/webstorage/#user-tracking Our text is informative. The Web Storage text is normative, but doesn't contain requirements language (SHOULD, MUST). What aspects of this text should be make normative and what level of requirements ?
This is related bug 27168. I believe Henri has some text he is planning to propose which should resolve this as well.
We also have bug 27270. Maybe we should merge the two, possibly bringing the proposed text from that bug here.
{The following is Bug 27270's description by Henri Sivonen.} In order to give users the opportunity to cause a discontinuity in the ability of a site, third parties who scripts the site includes or a network MITM who injects EME usage into a non-https site to track the user across time, please require that distinctive identifiers be forgettable and regeneratable. (Start proposed spec text for a *normative* section) Implementations MUST ensure that the user may request distinctive identifiers to be forgotten such that new different distinctive identifiers are generated in the place of the old ones when distinctive identifiers are needed subsequently. It is RECOMMENDED that users be able to request that distinctive identifiers be forgotten on a per-site basis, particularly as part of a "Forget about this site" feature that forgets cookies, databases, etc. associated with a particular site in an operation that is sufficiently atomic to prevent "cookie resurrection" type of recorrelation of a new identifier with the old by relying on another type of locally stored data that did not get cleared at the same time. Note: The most obvious way to meet this requirement is to ensure that the salt contemplated in the above note (actually in bug 27269) be forgettable such that a new salt is randomly generated when needed.
*** Bug 27270 has been marked as a duplicate of this bug. ***
https://github.com/w3c/encrypted-media/commit/7e62ee2908ec9492a18bb26059b1ccffec4fc967 incorporates much of Henri's text quoted in comment #6. We still need to address comments #1-3.
The last edit: 1. Requires clearable IDs. 2. Recommends clearing them along with cookies. 3. Recommends clearing them per site and taking precautions for cookie resurrection. This edit addresses the subject of this bug and seems sufficient to close it in my view. The additional suggestions in comments 1-3 had other possible tracking mitigations, but I think were included primarily to provide model text for making IDs clearable.
Although not directly related to the original bug, the following commits address comments #1-3. https://github.com/w3c/encrypted-media/commit/062ee2b7563e9e2c8a80deeed101e713be75d6cb and https://github.com/w3c/encrypted-media/commit/3580fd77fbe0c01ec12e34075d093b7d4a1bc2ec integrate more text based on the Privacy and Security sections of the specifications in comment #1. https://github.com/w3c/encrypted-media/commit/fd25fde785d1c6e6805d71ea313bd07f458578b9 and https://github.com/w3c/encrypted-media/commit/ff22f4e7cd35b3e8c802b90506f33188604666e9 make most of the Security and Privacy sections normative. All issues raised in this bug have now been addressed.