- 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>
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