RE: Transitive third party exceptions

If I understand you right, this complicates things much more than I originally thought, because this introduces yet another variation of what DNT means to yet another party.  According to this, a 3rd party in an ad chain that is not directly embedded on the 1st party site has a different set of rules than either a 1st party OR a 3rd party under DNT OR a 3rd party with an exception.  It sounds like you are suggesting that a 3rd party in the chain of a 3rd party with an exception can USE data collected on the current hit in conjunction with their stored user profile to do its job, but cannot augment the stored user profile with the data collected on this hit, nor share said data.  I do not think we want to introduce another variation of limitations unless the benefit is huge.

>That is exactly the point why you want to have transitive permissions. B could do the gender reference but only in the context given by A. B could not store the gender reference and sell it with the data record to Z. That was the limitation I was talking about.

It doesn’t really work that way (at least not usually).  Gender does not get passed down from 1st party through all the appropriate 3rd parties.  Rather, two 3rd parties that both know a little something about the user bid on the right to serve the user an ad.  One of the ad networks may know the gender of the user from a previous interaction and therefore be willing to pay a little more to show the user an ad than the other network which has no gender information.  So, A does not give B the context under which it performs its job.  B, C, ...Z have to be able to perform their function in their own context, and if they cannot due to DNT limitations, than the exception granted further up the chain did not accomplish much.


-----Original Message-----
From: Rigo Wenning [mailto:rigo@w3.org] 
Sent: Friday, June 01, 2012 11:54 AM
To: public-tracking@w3.org
Cc: Kevin Smith; ifette@google.com
Subject: Re: Transitive third party exceptions

Kevin, 

On Tuesday 29 May 2012 17:02:59 Kevin Smith wrote:
> This is very interesting.  I don’t think I understand exactly what you 
> mean.  Are you suggesting that 3rd parties B, C ... would not get 
> DNT:0?

No, how would the user agent know what to send to those as they are subsequently used without being known by first party or user. 

> What purpose limitation would entity C be under?  And how would it 
> know the difference?

If they receive data without receiving DNT;0 they know that this is under the known limitations. I imagine that the ad exchange networks and auction platforms will invent a key whether a given user is auctioned under DNT rules or not. 

> If entity C has limitations and cannot function as it normally would, 
> then this inherently limits entities B and A because, although they 
> may think they can function fully, they cannot.

See, they can function fully for the service they were engaged for. But the limitation would be to not allow secondary and fully arbitrary independent re-use of the data acquired from the known third party. Secondary use would only be allowed if the service itself gets a DNT;0

> Here is a ridiculously simplified example - let's say that entity A 
> has an exception and is therefore allowed to target a user based on 
> gender.  However, entity A does not actually serve the ads, so it 
> includes entity B and asks entity B to serve up an ad that will match 
> the user's gender.  If entity B is not allowed to know the gender, or 
> reference its visitor profile for the user etc, then it cannot serve 
> an ad based on gender, so it either returns failure, or a non-targeted 
> ad.  In this case, entity A was not able to fulfill its function 
> because it was dependent on entity B being able to fulfill its function.

That is exactly the point why you want to have transitive permissions. B could do the gender reference but only in the context given by A. B could not store the gender reference and sell it with the data record to Z. That was the limitation I was talking about. 

Rigo

Received on Friday, 1 June 2012 21:21:18 UTC