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#TS
>> 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#TS
>> V-

Received on Thursday, 30 October 2014 22:11:50 UTC