Re: DNT:1 and "data append"

On Tuesday 26 March 2013 22:06:36 Nicholas Doty wrote:
> 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. 

If a first party goes to a third party service and says: "Give me data 
for category X" and uses that data to customize the first party 
experience, that is OK. 

If  a first party singles out a user, asks the third party: "Give me 
data for the bucket with this one user" it can't work anymore. The first 
party is sharing personal data. 

If a first party is collecting profile data (US only) under DNT:1, it 
has to anonymize the data before sharing that profile data. Most 
statistic operations fall into this anonymous category. Unless the 
categories are so fine grained that they allow to single out an 
individual.

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

But here, this is like the viral effect of the GPL. You can't buy a 
profile, augment it with first party data and sell it again. First party 
data collected under DNT:1 has to remain in the first party. If you mix 
it into your big brother database, the entire database can only be 
shared, if it is cleaned from this first party DNT:1 data beforehand.

DNT, as it currently stands, does nothing against the first party 
becoming the Leviathan. This is by design. Everybody knows that I 
personally find that unjust and a bad idea because http doesn't 
distinguish between GET requests from first and third parties. But the 
Group has decided otherwise. The "append" discussion should be frank and 
either accept the first party Leviathan or ask the chairs to re-open the 
first/third party issue. This is then a different discussion.
> 
> 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.

The service provider has no own right on data, by definition. This is 
like renting a read-only database in a computer into the office of the 
first party, which matches the case above. As soon as they write 
anything back into the database, they contaminated that database and 
have to give it to the first party at the end of the contract. First 
parties can use personal data from all over the place, but they can't 
write back to all over the place. Again, if you want to avoid the first 
party Leviathan, you have to open the 1st/3rd party question again. 
Prohibiting "append" is somewhat transgressing into that territory. 

 --Rigo

Received on Wednesday, 27 March 2013 09:45:16 UTC