W3C home > Mailing lists > Public > public-tracking@w3.org > March 2013

RE: DNT:1 and "data append"

From: Mike O'Neill <michael.oneill@baycloud.com>
Date: Wed, 27 Mar 2013 12:43:50 -0000
To: "'Nicholas Doty'" <npdoty@w3.org>
Cc: <public-tracking@w3.org>
Message-ID: <036901ce2ae8$bbf13710$33d3a530$@baycloud.com>
Nick,

If an identifier is unique and persistent, for example a first or third
party cookie containing unique bit pattern, then it can be used to link
records over time. It does not have to encode other personal identifying
data, so it does not matter if it is encrypted or not. If a cryptographic
function is applied you still end up with a unique bit pattern. If it was no
longer unique there would no point in sharing it.  What I am worried about
is allowing first-parties, when DNT is set, to share user unique bit
patterns with others so they can record over time the web activity history
of the same individual (or their UA session). Persistency of identifiers is
key to "tracking" and we should not introduce text defining exemptions that
obscure that fact.

Mike
 

-----Original Message-----
From: Nicholas Doty [mailto:npdoty@w3.org] 
Sent: 27 March 2013 05:07
To: Rigo Wenning
Cc: Mike O'Neill; 'Jeffrey Chester'; 'Chris Pedigo'; public-tracking@w3.org;
ifette@google.com; 'David Singer'
Subject: Re: DNT:1 and "data append"


On Mar 20, 2013, at 2:11 PM, Rigo Wenning <rigo@w3.org> wrote:

> Mike,
> 
> good point. But if they collect that identifier in a first party 
> context, they can't share it with the third party. Thus the third 
> party can not use that identifier to select the appropriate profile 
> data to deliver to the first party. Because otherwise, the third party 
> would get the information that user cookie xyz1234 is now visiting
example.com.
> 
> So if they share uniqueID with third parties or offline data providers 
> under data append strategies, that would not be conformant under the 
> current specification IMHO.
> 
> I still think they are saying the same thing. It may be that some 
> still believed that the current text would allow append. I don't think 
> it does as it rules out necessary preparation steps for data append.

I believe this requires some assumptions (including assumptions that may be
empirically incorrect) about how data append is accomplished.

As Chris has pointed out earlier on this thread and during past calls, it is
possible (using cryptographic techniques, or as Chris put it "double blind")
where matching of records can be done without revealing your list of
identifiers to the other party. Or, a party might have obtained a full data
set from a third party which already include the identifiers -- then the
first party matches the identifier against the data set to learn more about
the user (their address, their shopping habits, etc.) to personalize the
first-party content.

Second, Chris has proposed the possibility that the additional data provider
could act as a service provider to the first party -- in that situation, the
first party shares the identifiers in the clear (rather than through the
cryptographic protocol) with the service provider, who is enforced by
contract not to re-share them or use them independently. The service
provider uses that list of identifiers to look up matching records in their
data set and return data about the user (shopping habits, change of address
info, etc.) with the first party.

Hope this helps,
Nick
Received on Wednesday, 27 March 2013 12:44:20 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:07 UTC