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

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) 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#TSV- <http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#TSV-> ?
>
> 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