RE: Indirect DNT Processing (Proposed)

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

Creating a special alleviation or permitted use for ad exchanges will  be difficult and is anyway unnecessary. This use case only arises when consent is obtained by one or more downstream ad servers because if none of them have consent the ad exchange just does not share the UID.

When a downstream ad server explains to the user what the consent is for, they can also ask for consent for their service providers. They should have a data processor (service provider)  agreement in place with the ad exchange so that it has no independent right to use the data (in this case the UID).

Then the issue becomes the technical one of allocating DNT:0 (or OOBC) consent by the user to the ad exchanges. This is similar to the “same-party” use case where we ended up with the cookie-like domain rules, which only solved part of the problem anyway.

As we discussed back then, there are already mechanisms in place that can do this e.g. by supporting multiple other-origin iframes on the consent acquisition page.  It would be much simpler (and more transparent) ultimately if we handled it in the UGE API but this would be hard to reach agreement on in a reasonable time(we would have to break some of the same-origin restrictions on web-wide consent, and there are other problems), so maybe should be left to DNT2.0. There are already techniques like multiple iframes that could be used anyway, though not transparently.

Mike



From: TOUBIANA Vincent [mailto:vtoubiana@cnil.fr]
Sent: 23 October 2014 10:29
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

iQEcBAEBAgAGBQJUSNYvAAoJEHMxUy4uXm2J2oQH/ikEPoNT91c+xysavfdy01lh
t4LtxAafGs5S2Exc9jHU2jyFgJVo669XWrnz1ee0yGWaFQZ4vRdC5YclTSlta8VW
w8jhPKOEG74VyZ79tnqfy+0JY4K0q/llyUoB+buXQTJD87fDFNXjTIPg5sb/TXy4
dtGO8lPplYNkVkUFxZ5eH44iulfnUb77mJAvrmKha+/tn0gt5xxFmzALb7iY2L+C
AOo2FhT8763xG3yoJNlERT8Go6GQFnSx1i14Q4fTdTZ51ia5AJq81apv6eFK58wR
bgv3YAbL+/n5CqIYYQt3aTT2n718y1xo/Jo5Yz/7G/dQ0Kqsbu1Qyznyh+7TJ1Y=
=i+Ja
-----END PGP SIGNATURE-----