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

Rob,
In #2 - that is correct - the publisher is passing the information to the DSPs "through" the Exchange.  The Exchange does not make this decision - the publisher decides who to include and/or block from bidding on its inventory.
- Shane Shane Wiley
VP, Privacy & Data Governance
Yahoo
      From: Rob van Eijk <rob@blaeu.com>
 To: Shane M Wiley <wileys@yahoo-inc.com> 
Cc: TOUBIANA Vincent <vtoubiana@cnil.fr>; Justin Brookman <jbrookman@cdt.org>; Nicholas Doty <npdoty@w3.org>; Tracking Protection Working Group <public-tracking@w3.org>; Roy T. Fielding <fielding@gbiv.com> 
 Sent: Thursday, October 30, 2014 3:57 PM
 Subject: RE: ISSUE-262: guidance regarding server responses and timing
   
Shane,

#1 ok, fair
#2 It may depend on the use case. A publisher could pass ad information 
to an exchange. The exchange then composes a bid request and send that 
request to several DSP's. This use case is not mere conduit in my view.

Rob



Shane M Wiley schreef op 2014-10-30 23:18:
> 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-