RE: ISSUE-262: guidance regarding server responses and timing

Rob,

That is incorrect.

#1 - The exchange houses the bid transaction but does not set the rules of the bid "winner" - the bid requester sets these rules (but is most often the highest bidder but sometimes quality is selected over bid price).
#2 - The exchange houses the bid transaction but does not initiate the request - the bid requester (the inventory supply - typically a publisher or 1st party) actually launches the request and the Exchange forwards the request to those parties interested in bidding (the content demand - typically an advertiser or 3rd party).

- Shane

-----Original Message-----
From: Rob van Eijk [mailto:rob@blaeu.com] 
Sent: Thursday, October 30, 2014 3:11 PM
To: Shane M Wiley
Cc: TOUBIANA Vincent; Justin Brookman; Nicholas Doty; Tracking Protection Working Group; Roy T. Fielding
Subject: RE: ISSUE-262: guidance regarding server responses and timing

Shane,
I diagree for two reasons. (1) The key function of the ad exchange is select the highest bidder and (2) the ad exachange initiates the bidding process with a bid requests and therefore initiates the communication with all bidders. These two conditions rule out "mere conduit" in the EU.
Rob

Shane M Wiley schreef op 2014-10-30 17:50:
> Rob,
> 
> Incorrect - they are merely a conduit.
> 
> I don't believe I'm asking for a specific exception for Exchanges but 
> rather for any Service Provider where the actual transaction recipient 
> is not visible to the user agent and therefore cannot receive their 
> appropriate DNT signal for their domain appropriately.  The overriding 
> rule should be once a party is able to receive their domain's own DNT 
> signal then they must honor it.
> 
> - Shane
> 
> -----Original Message-----
> From: Rob van Eijk [mailto:rob@blaeu.com]
> Sent: Thursday, October 30, 2014 2:35 AM
> To: TOUBIANA Vincent
> Cc: Shane M Wiley; Justin Brookman; Nicholas Doty; Tracking Protection 
> Working Group; Roy T. Fielding
> Subject: RE: ISSUE-262: guidance regarding server responses and timing
> 
> TOUBIANA Vincent schreef op 2014-10-30 10:14:
>> Also, what I understood from previous discussion was that only the 
>> data contained in the current Bid Request was used to assess the Bid, 
>> while now I understand from the "Real Time Bidder Policy"  is that 
>> the "assessment" is also based on data collected from previous bid 
>> requests, even if the bidder lost.
> 
> Precisely, the ad exchange plays a role that goes beyond "mere 
> conduit".
> 
> Shane M Wiley schreef op 2014-10-29 23:08:
>>> As the Exchange is a neutral party I’d recommend we attempt to 
>>> develop a carve-out/permitted use for this type of entity.
> 
> I object to a permitted use for data exchanges. There are many 
> different types of exchanges - e.g. private, public, data, etc. - and 
> new (technical and business)models for exchanges will follow. The Ad 
> Exchange is - in my view - (jointly) responsible for the ad boundaries 
> that are used by the bidding algorithms. A permitted use for these 
> entities is synonymous with 'kicking the can down the road'.
> 
>>> If we create a paradigm such that all members of an Exchange must 
>>> support DNT, then the Exchange will not support DNT – and as others 
>>> will likely see this as a competitive disadvantage they will not 
>>> support it either.
> 
> I am not convinced by the argument, that due to a perceived 
> competitive disadvantage other Exchanges will not implement either.
> The effect could well be that users will shunt exchanges that ignore 
> DNT, which could turn engineering privacy into the rtb protocol a 
> competitive advantage.
> 
> Rob
> 
> 
> TOUBIANA Vincent schreef op 2014-10-30 10:14:
>> So we agree that the constraint is not on the retention of the data 
>> but it's on the use that can be made of it (i.e. no destruction).
>> 
>> Also, what I understood from previous discussion was that only the 
>> data contained in the current Bid Request was used to assess the Bid, 
>> while now I understand from the "Real Time Bidder Policy"  is that 
>> the "assessment" is also based on data collected from previous bid 
>> requests, even if the bidder lost.
>> 
>> Vincent
>> 
>> DE : Shane M Wiley [mailto:wileys@yahoo-inc.com] ENVOYÉ : jeudi 30 
>> octobre 2014 00:45 À : TOUBIANA Vincent; Justin Brookman; Nicholas 
>> Doty CC : Tracking Protection Working Group; Roy T. Fielding OBJET :
>> RE: ISSUE-262: guidance regarding server responses and timing
>> 
>> The "Data Use" and "Real Time Bidder Policy" sections cover use of 
>> data only for assessment and analytics (prediction algo - not user 
>> specific). Not to be used for any form of profiling. This is in-line 
>> with what I've been saying.
>> 
>> - Shane
>> 
>> FROM: TOUBIANA Vincent [mailto:vtoubiana@cnil.fr]
>> SENT: Wednesday, October 29, 2014 4:04 PM
>> TO: Shane M Wiley; Justin Brookman; Nicholas Doty
>> CC: Tracking Protection Working Group; Roy T. Fielding
>> SUBJECT: RE: ISSUE-262: guidance regarding server responses and 
>> timing
>> 
>> Thank you for the clarification Shane, but from what I understand of 
>> these guidelines 
>> (https://www.google.com/doubleclick/adxbuyer/guidelines.html [1]) at 
>> least Google has a different retention policy for bidders.
>> Also, could you confirm or infirm that user-agent will not be in a 
>> position to block the UID once they receive the "?" response?
>> 
>> Vincent
>> 
>> -----Original Message-----
>> From: Shane M Wiley [mailto:wileys@yahoo-inc.com]
>> Sent: Wed 10/29/2014 11:28 PM
>> To: TOUBIANA Vincent; Justin Brookman; Nicholas Doty
>> Cc: Tracking Protection Working Group; Roy T. Fielding
>> Subject: RE: ISSUE-262: guidance regarding server responses and 
>> timing
>> 
>> Justin is correct, Vincent is incorrect - Bidders are subject to 
>> bid-loss/data destruction constraint, not the Exchange (since it's 
>> the Exchange hosting the bid transaction).
>> 
>> - Shane
>> 
>> From: TOUBIANA Vincent [mailto:vtoubiana@cnil.fr]
>> Sent: Wednesday, October 29, 2014 3:19 PM
>> To: Justin Brookman; Nicholas Doty
>> Cc: Tracking Protection Working Group; Roy T. Fielding
>> Subject: RE: ISSUE-262: guidance regarding server responses and 
>> timing
>> 
>>> Also, I believe Shane indicated on a previous call that losing
>> bidders are typically prohibited from retaining (or using?) lost bid 
>> data.
>> 
>> If this prohibition applies, I believe it's only for the ad-exchange.
>> I don't think the bidders are subject to this constraint.
>> 
>>> And a particularly wary user agent could always deny access to
>> cookies or otherwise limit an exchange's access to tracking resources 
>> when it receives a ? TSV . . .
>> 
>> That would not work: the user-agent receives the "?" only after it 
>> has sent its UID to the ad-exchange. It has then no control over the 
>> diffusion of the (UID,URL) to the bidders.
>> 
>> Vincent
>> 
>> On Oct 21, 2014, at 6:43 PM, Nicholas Doty <npdoty@w3.org> wrote:
>> 
>>> Our discussion last week of ISSUE-262 (guidance regarding server
>> responses and timing) focused on a question of ad exchanges or other 
>> servers that communicate with a number of other servers, for one of 
>> which it acts as a service provider. The question was how the 
>> exchange/real-time-bidding server should respond, for users that 
>> fetch the tracking status resource. In some cases, if the exchange 
>> server knows that all of its potential winning bidders/potential 
>> responders have a common DNT policy, the server could just respond 
>> statically with the tracking status resource that corresponds to the 
>> request and those downstream servers. But what if the server's 
>> downstream servers don't have a common DNT policy (some comply and 
>> some don't; some claim consent and some don't; etc.)?
>>> 
>>> Based on IRC conversation, here is what I would suggest for that
>> case:
>>> 
>>> A server that doesn't know ahead of time what server will win the
>> bid and where those downstream servers have varying/incompatible 
>> policies, the exchange server can respond to any tracking status 
>> resource requests with the tracking status value of "?", which we had 
>> previously defined for any resources for which the tracking behavior 
>> is dynamic.
>>> 
>>> 
>> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#T

>> S
>> V-
>> [2]
>> <http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#

>> T
>> SV-
>> [2]> ?
>>> 
>>> In order to comply with the TPE, the exchange server would need to
>> determine the appropriate tracking status from the downstream server 
>> that wins the bid and supplies the response. And in the response to 
>> the resource request (to load the ad, for example), the exchange 
>> server would send a Tk response header with the appropriate value. 
>> The server might also send a "status-id" field so that interested 
>> users could query the tracking-status resource that could then be 
>> specific to that fulfilling server (links to privacy policy, etc.).
>>> 
>>> Roy suggests that we might need to make a small change to the
>> requirements about the cached life of these values to correspond to 
>> this case (where the same URL might be fulfilled in different ways by 
>> different servers within a 24 hour period). I believe we'd indicate 
>> that the Tk: response value does not need to be valid for at least 24 
>> hours, but only for the request itself. That wouldn't change any of 
>> the expected caching behavior of tracking status resources. I believe 
>> that would just be a clarification added to either 6.7.2 or 6.3.1.
>>> 
>>> (The question also doesn't arise for advertising models where the
>> user agent is redirected to another server to deliver the ad itself 
>> -- in that case each server just responds to any tracking status 
>> resource requests based on its individual policy.)
>>> 
>>> Thanks,
>>> Nick
>> 
>> 
>> 
>> Links:
>> ------
>> [1] https://www.google.com/doubleclick/adxbuyer/guidelines.html

>> [2]
>> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#T

>> S
>> V-

Received on Thursday, 30 October 2014 22:20:42 UTC