[Bug 27268] Add a definition of a distinctive identifier

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

--- Comment #7 from Henri Sivonen <hsivonen@hsivonen.fi> ---
(In reply to David Dorwin from comment #6)
> (In reply to Henri Sivonen from comment #5)
> > (In reply to David Dorwin from comment #1)
> > > https://github.com/w3c/encrypted-media/commit/
> > > ce5d69ae56fc9cc890a02b132533431d54089780 adds the definition. It is mostly
> > > the the proposed text from comment #0.
> > > 
> > > I have some questions for Henri below.
> > > 
> > > (In reply to Henri Sivonen from comment #0)
> > > >  3) It is used in more than one session
> > > By "session", do you really mean MediaKeySession? What about sessions within
> > > the same MediaKeys object?
> > 
> > I think I don't understand the implications of the distinction well enough
> > to give an informed response at this time.
> 
> I want to understand the type of session you were referring to so that I can
> eliminate the ambiguity in the spec. I think the problem is that the
> identifier is the same between, for example, visits to a page. This could be
> a browsing session. I don't think you meant MediaKeySession, since
> MediaKeySessions share a MediaKeys object and CDM instance and thus likely
> share identifiers.

I meant anything that is a "session" from the DRM perspective and that the CDM
can store information about to revive in a later browsing session (i.e. after
the browser has been quit and relaunched). AFAICT, this means the features
under https://w3c.github.io/encrypted-media/#session-storage

> > > > or is potentially used in one
> > > > persistent session across the point of persistence.
> > > Please clarify and/or explain the purpose of this text.
> > 
> > The purpose of this text is to close a loophole where a never-ending
> > persistent session could carry around something that's seemingly a
> > throw-away (and, therefore, presumptively not distinctive) value like a
> > nonce, but it doesn't actually get thrown away in reasonable time and
> > becomes a tracking id (i.e. distinctive for practical purposes).
> 
> Is the never-ending persistent session internal to the CDM or is it left and
> used by the application? Any persistent session provides tracking just like
> a cookie. It's unlikely that persistent sessions would be identical on two
> systems. What is your specific concern beyond that?

The concern I had was an application being able to ask the CDM to persist a DRM
session and then in a later browser session ask the CDM to revive the DRM
session thereby correlating the two browser sessions and belonging to the same
user.

> Note: The user should be able to clear persistent sessions (like cookies),
> which should erase such an ID.

Do you mean that there should be UI that removes persistent sessions without
also removing all DRM-related persistent data for a site?

> > > >  * A nonce that's unique but used in only one non-persistent session.
> > > What is the importance of "non-persistent" here? (I did not include this in
> > > the change.)
> > 
> > See above about using a never-ending persistent session for tracking users.
> 
> Okay. If I understand correctly, you consider any nonce in a persistent
> session to be a distinctive identifier.

Right, because even though the nonce is "used only once" from the point of view
of being used in only one DRM session, it ends up being used more than one
browser session.

> I am arguing that any persistent session is likely to be a distinctive
> identifier by that logic. While such things could be used to track a user
> (unless/until the sessions are cleared by the user), I think this waters
> down the meaning of distinctive identifier and distracts from the far more
> concerning types of identifiers.

Fair enough.

> Perhaps we should add a note somewhere
> explaining out persistent sessions could be used to track users.

Works for me provided that the requirements that I proposed to trigger on
distinctive identifiers are changed to trigger both by the presence of
distinctive identifiers and the presence of persistent sessions.

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

Received on Monday, 19 January 2015 11:14:45 UTC