RE: tracking data (was Re: [TCS] comments on 17 Feb 2015 editors draft)

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

Justin,

That was not clear to me from the wording of your email last night, but I feel happier with that. It would help if you posted the entire text for the amended third-party compliance section so we can read it in its entirety.

Mike


From: Justin Brookman [mailto:jbrookman@cdt.org]
Sent: 09 April 2015 19:28
To: Mike O'Neill
Cc: Tracking Protection Working Group
Subject: Re: tracking data (was Re: [TCS] comments on 17 Feb 2015 editors draft)

The language you're referencing is still in the TCS:

Outside the permitted uses and explicitly-granted exceptions listed below, a third party to a given user action must not collect, share, or associate with related network interactions any identifiers that identify a specific user, user agent, or device. For example, a third party that does not require unique user identifiers for one of the permitted uses must not place a unique identifier in cookies or other browser-based local storage mechanisms.

Has anyone suggested removing that language?  I didn't see that in Roy's proposed edits.  I don't think anyone is arguing that third parties can use unique identifiers for non-permitted uses.  But we're not going to re-open the issue of unique identifiers for permitted uses at this point.  THAT would be a massive change.

On Thu, Apr 9, 2015 at 12:56 PM, Mike O'Neill <michael.oneill@baycloud.com> wrote:
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Justin, I agreed to the wording for the section on permitted uses only because there was already existing text in the third-party compliance section covering the majority DNT case.

The compliance section said servers MUST NOT “associate with related network interactions any identifiers that identify a specific user, user agent, or device”.
It also gave an example, not covered by a permitted use, where servers “MUST NOT place a unique identifier in cookies or other browser-based local storage mechanisms”.
It also said “MUST NOT collect, share, or use tracking data related to that interaction”, which I firmly understood to indicate the “enablement” interpretation of tracking data.

Removing this is a massive change in terms of the fundamental meaning and clarity of the document.

Mike




From: Justin Brookman [mailto:jbrookman@cdt.org]
Sent: 09 April 2015 17:30
To: Mike O'Neill
Cc: Tracking Protection Working Group
Subject: Re: tracking data (was Re: [TCS] comments on 17 Feb 2015 editors draft)

I don't see how any of this could be characterized as a "massive" change.  Which change do you object to --- the removal of "tracking data" from the non-normative section of de-ID, the inclusion of agreements within the non-normative section of de-ID, the removal of "tracking data" from third party compliance, or something else?

The data minimization section (http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#data-minimization-and-transparency) that addressed the issue of unique identifiers was resolved months ago; you withdrew your change proposal on unique identifiers because you were satisfied with the existing text. That section currently says A party must not rely on unique identifiers if alternative solutions are reasonably available.

On Thu, Apr 9, 2015 at 11:21 AM, Mike O'Neill <michael.oneill@baycloud.com> wrote:
- - -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Also for the record:  I strongly object to such late and massive changes being made to the text, especially the de-identification section, which was the result of much consensus building and a formal Call for Objections, and now also to the third-party compliance section  which contained the essence of the document .

Astonishingly, the text no longer contains any reference to personal identifiers which, as I have said - and everybody knows, is the intrinsic mechanism of tracking. The logical structure has also been inverted so there is now an assumption of collection, with compliance defined by explicit conditions for processing. These conditions are opaque and unintelligible to users and implementers. A lawyer could drive a coach and horses through them, letting bodies claim compliance while in fact not changing their behaviour at all.

The most important question any implementer will ask:

"Can a server executing a DNT request to a third-party resource use a persistent UID cookie, or another method that recognise the user in other interactions over time?"

This document now has no answer to that.

For the first time in years I was 30 minutes late to the 1 hour call, which had finished early by the time I arrived. I therefore ask that the issue be re-addressed next week.


Mike

> -----Original Message-----
> From: Walter van Holst [mailto:walter@vanholst.com]
> Sent: 09 April 2015 13:47
> To: public-tracking@w3.org
> Subject: Re: tracking data (was Re: [TCS] comments on 17 Feb 2015 editors
> draft)
>
> On 2015-04-08 21:50, Justin Brookman wrote:
>
> > Walter had previously objected on the mailing list to removing
> > "tracking data" from the non-normative discussion of
> > de-identification.  However, participants on the call today didn't
> > think the removal of the term weakened that provision.
> > De-identification already requires technical processes to ensure that
> > *no one* can re-identify the data; the non-normative language simply
> > notes other prophylactic steps that can be taken to address the
> > persistent possibility of reidentification in the future.
>
> For the record: I do not object to the removal of  the term "tracking
> data". I specifically provided alternative wordings that would allow for
> its removal while retaining the intent and scope of the text. I have
> always been of the opinion that we can have a good spec without such a
> term, even though it might be helpful for getting there.
>
> The core of my objection is that in the new text the obligation for
> having "business processes" that preven re-identification could be read
> narrowly and would not prevent sharing de-identified data with a
> non-compliant party for the purpose of that party re-identifying that
> data. All while being able to claim DNT-compliance.
>
> Regards,
>
>   Walter
>
> P.S. in the IRC log I noticed " if I'm embedded in the NYT and remember
> the user's visit to the NYT, that's not by itself tracking, I think.". I
> think that is a clear-cut case of tracking. A DNT-compliant third party
> embedded on the NYT website should basically ignore any information of
> me being on that site (while sending DNT:1) unless necessary for and
> confined to a permitted use, let alone which article. Like Shane
> correctly pointed out, rate-limiting is a permitted use, but that is not
> dependent on me being on the NYT website.
- - -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.4.103.5490 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJVJpkPAAoJEHMxUy4uXm2JbLAH/2jxWxuTwhYHH2EmFZUAGQRy
iTTm1GAMwLO17ts7Mozrc4RrA1VzxbNidfun3QpZLKlCdFGP9ujq8V/GQgzvuw3Q
qLXurSuF4rlG6nJlxGC/o+w8DNlNKHHptL8PxACG/AfHH1DF4+fzFt5f89n0xzIl
iEidYY8GJInfOekwOs67+xfo+lipfmE+Pq2VGAPK57k4DbBIy1Va2wzlC99yfQ4f
Cm1pz8iEOKTcA5xdUKoYk06vLqP21Gxu5wCGO9f53JynNSK16U71SQeonevVC4Pg
++UMIM/uBPLXds21xXPL5FWiI3HkUX+G477hxGNwRTVaZGorzK/2inwYF/OAu9s=
=zCW+
- - -----END PGP SIGNATURE-----

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

iQEcBAEBAgAGBQJVJq9CAAoJEHMxUy4uXm2Jlx4H/3OEDtBW5LDwgyR7vDmkRUuj
8Dxtsas7qYHtatDhCzWVKGGXhe4kLOndsXVxBCR/ZsdjnySgCYKsyfR4T/WBeLaM
VCoq85PEKJ4nf8S7JEf1CNiSPV9yQvrdNklxY1HuYzt49ieh/s1iBMU1CYj7lDXi
l7Efd5rcJpY3QMkp1sbPY5k0t9psCiHK1/OWjHMp9cqOApqF/onortRPBZ7s45hR
HVYsS+FytJlGu4TlwH2SdVb0E7yJ3ukj6axxGDLJrqF43eXG77gUb/GvO+6CVhbH
JpYxD3IUa+lwzSO+P+GxIUojchs4ACTUcNKBKIaQ3vh9kwM+bzjGuQLoMoUZK8g=
=vMWc
- -----END PGP SIGNATURE-----

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

iQEcBAEBAgAGBQJVJscpAAoJEHMxUy4uXm2JrDwIAJ6g1OkGn9B8kyXwDUrpqL/7
rEBBKkj4/QjQUeKiPtp/ezFLNbGjn7NHVPR1CGsJL/JbaBuh5Eh574E9XxhFtELs
zXf5elWcAFWVe2uLgBJXiJhiQtcR2BhiUrHXYm0Os3DeOgj4Y/AlKrIjsBefGXGX
KCdakqxvY+hb/yEeFeamGhH8NTqerWDSx/NkG1X/YS4VlnxYEoMxhQo1fDSWywsF
vJmmpW7ZEu00tEKtdmEOWHOAkuuik344cAeMPM4BNlrLQcZX/NKwAEkF5o16R3Kb
aE4bMTNeYFKQL/NeSNK29l6+d/WhIbe42ZhJVbbCZmXJMDUHP42euccnA7kyHWA=
=8Wd6
-----END PGP SIGNATURE-----