This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
I oppose adoption of this proposal due since it would dictate policy for the use of EME, which IMO is the prerogative of users of EME, and not the EME specification. In other words, I believe EME should restrict itself to defining mechanism, and not policy. If it is desirable to define a normative policy or set of policies that can be optionally adopted for standardized uses by some EME user, then such policy(ies) may be defined in a separate document and adopted (or not) by EME users as they see fit.
We also have bug 27166. Maybe we should merge the two, possibly moving the proposed text from comment #0 there.
I copied the original description to bug 27166. We'll continue the discussion and work there. *** This bug has been marked as a duplicate of bug 27166 ***