RE: Deidentification (ISSUE-188)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I agree that the identifiers should be taken out of the server side data but my example is about encouraging transparency or machine discoverability. The user or user agent cannot confirm that references to the UID have gone in the server, but it is possible to see stored cookies etc. All I am saying is that an extra step of deleting (removing, scrubbing, overwriting, stomping on whatever you want to call it) UIDs from the browser helps transparency and is easy to do, so why not call for it. Many if not most AdChoices implementations already do that.

Mike

> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@gbiv.com]
> Sent: 29 August 2014 00:42
> To: Mike O'Neill
> Cc: David Singer; <vtoubiana@cnil.fr>; <rob@blaeu.com>; <public-
> tracking@w3.org>
> Subject: Re: Deidentification (ISSUE-188)
> 
> We don't seem to be talking about the same problem space. De-identification is
> something that usually occurs offline, long after the user agent has come and
> gone. We can't assume the user agent will ever visit the same domain again.
> 
> If we were talking about the time of the request, then it is simpler to just avoid
> setting an identifier of any kind. If the identifier is actually necessary for
> communication or state, then we are unlikely to have a state where it is deleted
> (expired, maybe, but even that is inconsistently implemented by UAs).
> 
> In any case, both would be covered by the general advice I described.
> 
> ....Roy
> 
> 
> > On Aug 28, 2014, at 1:01 PM, "Mike O'Neill" <michael.oneill@baycloud.com>
> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Not for cookies or the cache. A set-cookies header with an expiry in the past
> (or clearing the ETag value if in the cache) would do it. Even for DOM storage
> you just need to send the JavaScript in the content (localStorage.Clear(); or
> localStorage.removeItem(UID);), you do not have to wait for a callback. This is
> how it is done now by loads of AdChoices or e-privacy compliant
> implementations.
> >
> >> -----Original Message-----
> >> From: Roy T. Fielding [mailto:fielding@gbiv.com]
> >> Sent: 28 August 2014 20:32
> >> To: Mike O'Neill
> >> Cc: David Singer; <vtoubiana@cnil.fr>; <rob@blaeu.com>; <public-
> >> tracking@w3.org>
> >> Subject: Re: Deidentification (ISSUE-188)
> >>
> >>>> On Aug 28, 2014, at 2:55 AM, "Mike O'Neill"
> <michael.oneill@baycloud.com>
> >>> wrote:
> >>>
> >>>>> Data is permanently de-identified when there exists a high level of
> >> confidence that no human subject of the data can be identified, directly or
> >> indirectly, by that data alone or in combination with  other retained or
> available
> >> information.
> >>>
> >>> Roy, I think this is a good definition. Can we add the non-normative specific
> >> example about UIDs below. The clause about a enabling communication and
> >> requested service is there to cover publisher logins and session state (and IP
> >> addresses).
> >>>
> >>> Non-normative example:
> >>>
> >>> In the interests of transparency this implies that any data used or stored in a
> >> user agent or device for the purpose of identifying it in subsequent requests,
> >> unless solely used to enable communication or to supply a service requested
> by
> >> the user, will have been deleted or, if this is unfeasible, otherwise made
> >> ineffective.
> >>
> >> I don't think it implies anything of the sort, so this would be a normative
> >> addition. It isn't a good idea to suggest that servers delete client-side
> storage,
> >> since the only way to do that is pervasive callbacks with no privacy at all, and
> >> there might well be identifiers that are still effective for other (still identified)
> >> data sets. What matters is that they not be traceable to the de-identified
> data.
> >>
> >> A better suggestion would be to take steps to ensure the de-identified data
> does
> >> not contain any client-side identifier, nor data sufficient to generate a client-
> side
> >> identifier, since that would likely remain an indirect identifier for the user.
> >>
> >> ....Roy
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.13 (MingW32)
> > Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
> > Charset: utf-8
> >
> >
> iQEcBAEBAgAGBQJT/4qsAAoJEHMxUy4uXm2JHpMIALSdUsWjT7Lkv6BNk/GS430
> e
> > pHjGrRAeh2BAzauLyZD2y/5RwxifYwTY8Y/0lqa/S7TGczIoMllgkOhGx1iI5S/I
> > YN6jKFUmSgb6pq2BL5CsIACelDtvr64S6B4393C8fXTuPydXNYf7a83qwz3b+KyS
> >
> SRrEXag2ljJ9Gc8ruCrbfL56HvQndG3C4m22rdQwAKcdo6sAVUBM2EOvNMy8t2m
> m
> > vEiaJpYd7Bq9Gj+q+/HKjNAIz7rYUiySb8qaXzWuMJPHKYda0Yfgx0kXu2B62Bj7
> >
> YwHMrfJ4gELqAAtvns6tNCNv3SkvcEvwvPdGY4NEh6yysKnuj1qvNs7CQRuq1Cg=
> > =W69e
> > -----END PGP SIGNATURE-----
> >

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJUAIBIAAoJEHMxUy4uXm2Jo3IIAKeDlJBFm/CTax3xaKalP+lm
5qO2/NpRd+c8NMNuDdGmXiVRcMQxTRppo53kmcuvmHR85PMBoKzjrifAqmpdJK4e
sCp8DC24rYB/5uRGyCKTM5L7Nr5AhGpGicdmUckzyN7REVFT3ro0NGzHxw8CeIZX
VBdy5o+tJNVPtUw3mpoIecYjy34f7H+KsZFn3RPO2BgXydZS5sETQKI59JR8l8s7
nnML52J1DRp8gpa7p3sPsmBGKwqJVqHUDFUjQlUJTL0RL3aODhYumQ00Z+omEl88
/lySLGafHJDdY/2GJY7YGaiuvAVYkr8HAicRS09DNpqrIDlSuyfdF9AS55StPnE=
=YHUd
-----END PGP SIGNATURE-----

Received on Friday, 29 August 2014 13:30:51 UTC