RE: Indirect DNT Processing (Proposed)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Vincent,

I can see how this could work, assuming the ad exchange was a service provider for the containing page controller. There would have to be matching tables in the down stream servers also, and there would have to be a step of communicating UIDs in-document when DNT:0 (because the set of UIDs in the ad exchange would have to be associated with the distinct set of UIDs in the down stream servers).

The problem becomes how is the algorithm checked, i.e. to make sure the UIDs are only transferred to DNT:0 downstream servers etc. There would be a compliance risk so code would have to be audited.


Mike

From: TOUBIANA Vincent [mailto:vtoubiana@cnil.fr]
Sent: 23 October 2014 23:26
To: Shane M Wiley; Tracking Protection Working Group
Subject: RE: Indirect DNT Processing (Proposed)


Shane,

My idea was to keep it as a one step process where the bid request would only contain the UID and only the win notice would contain the URL. I still don't understand how the ADX can broadcast (URL,UDI) in the bid request without violating the "Third party compliance" requirement to not share data (http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#third-party-compliance). Sending only the UID could solve this problem.

That being said, a two step process would actually work very well. Especially, if UGE status are directly reported in the "matching tables" hosted by the ad-exchange; in that case the "additional step" would have no impact at all on the transaction latency.

Vincent



- -----Original Message-----
From: Shane M Wiley [mailto:wileys@yahoo-inc.com]
Sent: Thu 10/23/2014 8:23 PM
To: TOUBIANA Vincent; Tracking Protection Working Group
Subject: RE: Indirect DNT Processing (Proposed)

Vincent,

The Bid occurs in a single pass so all relevant information is passed as part of the "offer to bid" transaction (URL, UID) the bidder would then check their UGE records for that particular UID to then determine if leveraging profile information would be possible in this transaction.  Attempting to make this a "two-step" process would slow down the transaction too much in a world where Ad Exchanges already struggle to meet SLAs with a single call structure.

- - Shane

From: TOUBIANA Vincent [mailto:vtoubiana@cnil.fr]
Sent: Thursday, October 23, 2014 2:29 AM
To: Shane M Wiley; Tracking Protection Working Group
Subject: RE: Indirect DNT Processing (Proposed)

Shane,

I have a clarifying question. In the precise case of RTB, when DNT is set, is it possible to only include in the Bid Request information about the user (i.e. the user id) but not about the current network transaction (i.e. no information related to the visited website)? That would allow website to check that they have a UGE before bidding, information about the visited website would then be only transmitted to the winning bidder.

This option would still allow RTB to take place while preventing information about a network transaction to be shared with third parties.


Vincent


De : Shane M Wiley [mailto:wileys@yahoo-inc.com]
Envoyé : mercredi 15 octobre 2014 17:33
À : 'Tracking Protection Working Group'
Objet : Indirect DNT Processing (Proposed)

TPWG,

I was asked to develop language for consideration of how to manage DNT signals within Real-Time Bidding (RTB) environments such as an Ad Exchange.  I've up-leveled the concept to "Indirect DNT Processing" to cover scenarios where a user's signal may move from a direct client interaction to one between servers (server-to-server).

[Normative]
For Servers in direct communication with the User Agent that then communicate further with other parties within the same transaction but outside direct communication with the User Agent, those Servers MUST convey the current DNT flag relayed to their domain to those other parties.  In cases where other parties have recent knowledge of their own domain's DNT flag or UGE MAY process the request leveraging that information but MUST respond appropriately in the status response that they have done so - which, in turn, MUST then be conveyed by the Server to the User Agent.

[Non-Normative]
This is intended to facilitate indirect communications through a transitive passing of permission to allow for DNT processing to occur even when a processor doesn't have direct access to the User Agent.  If the processor has direct information about their own domain's DNT setting with the User Agent, such as their last direct interaction with the User Agent, they may want to consider this in their transaction handling.

Question - While from a policy perspective the passage of the STATUS RESPONSE value makes sense I'm not sure if this works as cleanly with the current TPE handling of those statuses.  Should we add a new flag/field to state a response is being conveyed from another party as to not confuse the User Agent into thinking the response is coming from the server in which it is in direct communication?

- - Shane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJUSlIZAAoJEHMxUy4uXm2Jc+oH/jb30UG3TE175BmEWhhNu6j7
DxdGUn7UIIs/2cKXKHYcg9KMtREPzZlLY4MwZUPvi0k6tOVV7acnLX189W28fezE
4xq5i+Trl48XGw4OO50W7fsf+Q7p5QMIsBw0rJsKEm2TdeT0Fhr4+VGsty/P4LKq
BUflxVSQAMSGb1A6H2RgkBz4KtbHpht5AqpgpiIUhPGHJghobzoKGhPyIpkzYawY
+uQ9G+XLp0voSFgW9czAgC7wysEM3QM1GtbxEn3A8651mpTMerz4HuewKToPY4k8
sAgzI3hXi5GAhszP2hFUl/qnSQFi4zFpDVk0w7gh9vyN1numZwVfECc/m5GjTeU=
=xaOB
-----END PGP SIGNATURE-----