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

Rob,

I had hoped to avoid that but I agree - the lack of understanding of how Exchanges actually work by non-industry participants is too great to overcome via email.

Note - I'm not asking for a Permitted Use for Exchanges specifically, but rather in situations where an intermediary's domain is exposed to user agent and a downstream recipient of the transaction (without access to the user agent) has prior knowledge of a UGE, that they be able to use that in this case - which the Exchange then responding with a TSV of ? (per Nick's email thread).  

As the recipients of the Exchange transaction are being funneled through a Service Provider, I believe the Service Provider must convey the DNT signal as part of the transaction - no disagreements there - but they should be able to pass the cookie ID and page URL for assessment purposes - neither being used for anything outside of a permitted use.  It's our current use of "third party" that is confusing in this use case since the server with access to the user agent is themselves a service provider to the 3rd party bidders and therefore should be able to share the information with those parties under the protections afforded a Service Provider (as if they weren't there and were receiving the cookie ID, URL, and DNT signal from the user agent directly).

- Shane

-----Original Message-----
From: Rob van Eijk [mailto:rob@blaeu.com] 
Sent: Thursday, October 30, 2014 2:55 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,
The data processed in the ad exchange is user specific.

This discussion is not moving forward I am afraid, when the intention seems to be to head for a cfo for a permitted use.

Rob
Shane M Wiley schreef op 2014-10-30 20:56:
> Vincent,
> 
> We can look at edge cases but generally a dataset that has no 
> attachment to specific users or devices (either directly or through 
> side facts) meets the definition.
> 
> - Shane
> 
> FROM: TOUBIANA Vincent [mailto:vtoubiana@cnil.fr]
>  SENT: Thursday, October 30, 2014 12:37 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
> 
> De-identification requirements go beyond "it's not user specific"
> 
>  Vincent
> 
>  -----Original Message-----
>  From: Shane M Wiley [mailto:wileys@yahoo-inc.com]
>  Sent: Thu 10/30/2014 7:23 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
> 
>  "assessment"= "analytics/product improvement" and as long as it's not 
> user specific it is permitted under the de-identification requirement.
> 
>  - Shane
> 
>  From: TOUBIANA Vincent [mailto:vtoubiana@cnil.fr]
>  Sent: Thursday, October 30, 2014 11:17 AM
>  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
> 
>  Shane,
> 
>  My point was to clarify that Bidders are NOT subject to bid-loss/data 
> destruction constraint.
> 
>  Ad-exchanges may already have prohibition about profiling users, but 
> they do use the data for "assessment" which is not a permitted use. It 
> seems to me that support for UGE in RTB would need significant changes 
> on already addressed topics (permitted use, definition of service 
> provider, third party compliance).
> 
>  Vincent
> 
>  De : Shane M Wiley [mailto:wileys@yahoo-inc.com]  Envoyé : jeudi 30 
> octobre 2014 17:49  À : TOUBIANA Vincent; Justin Brookman; Nicholas 
> Doty  Cc : Tracking Protection Working Group; Roy T. Fielding  Objet : 
> RE: ISSUE-262: guidance regarding server responses and timing
> 
>  Vincent,
> 
>  Yes - the data can be used to remember you lost a bid and to enhance 
> your algorithms based on that fact. It's no one's intention to try to 
> use this information to remember anything about the user specifically 
> or to profile them in any way. If you feel stating that more expressly 
> covers the issue I think that would be acceptable to Exchanges (I 
> believe some would argue the current AdX language already prohibits 
> that).
> 
>  - Shane
> 
>  From: TOUBIANA Vincent [mailto:vtoubiana@cnil.fr]
>  Sent: Thursday, October 30, 2014 2:14 AM
>  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
> 
>  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<mailto: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:14:51 UTC