Re: Indirect DNT Processing (Proposed)

> On Dec 10, 2014, at 14:21 , Justin Brookman <jbrookman@cdt.org> wrote:
> 
>> 3. How does this interact with Exceptions? Perhaps some clarifying notes are in order?
> 
> Right, this we discussed on the call, and I’m not entirely sure I understand the answer.  I also don’t understand how Roy’s proposal intersects with Shane’s separate proposal to allow servers to use cached information about a UGE in order to claim an exception.  I know Nick had some concerns about this proposal, but I don’t know if Roy’s proposal was meant to address this issue (or reject it by not including).
> 
> Either way, I imagine a winning bidder who has consent should respond with a C in the Tk header field, yes?  It sounds like losers wouldn’t be able to retain even if they have consent to track (though not sure that’s much different than how RTB operates today).  It also sounds like the gateway couldn’t collect tracking data even if it had consent; again, not sure how different that is from today if they really are effectively service providers.

Yes, we need to look at the cases:

a gateway gets dnt:0 (as a result of an exception, or for other reason)
b gateway has out of band consent
c winning bidder has consent (but gateway doesn’t)
d losing bidder has consent (but gateway doesn’t)

In case (a) I think Roy said that the user is effectively giving consent to the whole transaction, that the dnt:0 will pass through to the bidders.  I think that that still means that only the winning bidder gets to track.

In case (b) I guess the gateway itself gets to track, but not pass on permission to track?

In case (c) I guess the winning bidder returns an indication saying it thinks it has consent (even though it didn’t get a dnt:0)?

In case (d) I think it’s irrelevant; losing bidders never get to track.

I think we’re going to have to explain this a little.



David Singer
Manager, Software Standards, Apple Inc.

Received on Wednesday, 10 December 2014 22:29:19 UTC