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

Jeff,
You're lumping several concepts together which isn't very helpful.  Doubleclick is an ad network; AdX is an Exchange.  They serve different functions.  And yes a trading desk or agency can front the relationship for an advertiser but the same dynamics exist within the exchange process.  

In all cases, the Exchange is merely a service provider to the participants in the Exchange and should be allowed to pass information through to those participants (including the DNT signal) so they act appropriately - just as if they were communicating with the user agent directly and received the same information in that fashion. Shane Wiley
VP, Privacy & Data Governance
Yahoo
      From: Jeffrey Chester <jeff@democraticmedia.org>
 To: Shane M Wiley <wileys@yahoo-inc.com> 
Cc: Rob van Eijk <rob@blaeu.com>; TOUBIANA Vincent <vtoubiana@cnil.fr>; Justin Brookman <jbrookman@cdt.org>; Nicholas Doty <npdoty@w3.org>; "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>; Roy T. Fielding <fielding@gbiv.com> 
 Sent: Thursday, October 30, 2014 4:48 PM
 Subject: Re: ISSUE-262: guidance regarding server responses and timing
   
We also have programmatic direct, which can work involving ad agency trading desks, publishers, third party data providers, measurement companies.
The exchange can also have rules and relationships, depending on who it is, like Doubleclick.  
Jeffrey ChesterCenter for Digital Democracy1621 Connecticut Ave, NW, Suite 550Washington, DC 20009www.democraticmedia.orgwww.digitalads.org202-986-2220


On Oct 30, 2014, at 6:18 PM, Shane M Wiley <wileys@yahoo-inc.com> wrote:

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-