RE: Indirect DNT Processing (Proposed)

Mike,

Much like they would track UGE against the cookie ID, they also track opt-outs.

- Shane

-----Original Message-----
From: Mike O'Neill [mailto:michael.oneill@baycloud.com] 
Sent: Thursday, October 30, 2014 10:30 AM
To: Shane M Wiley; 'TOUBIANA Vincent'; 'Jeffrey Chester'
Cc: 'Rob van Eijk'; public-tracking@w3.org
Subject: RE: Indirect DNT Processing (Proposed)

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

Shane, if exchanges work like this then user’s web history is also being processed by bidders who have AdChoices opt-out cookies in their domain, but are unable to receive them. So when people click on the NAI/IAB opt-out pages how can they expect their opt-out to be honoured?

Mike





From: Shane M Wiley [mailto:wileys@yahoo-inc.com]
Sent: 29 October 2014 22:28
To: TOUBIANA Vincent; Jeffrey Chester
Cc: Rob van Eijk; public-tracking@w3.org
Subject: RE: Indirect DNT Processing (Proposed)

Vincent,

The core issue is that bidding entities domain is not presenting to the user agent, so it doesn’t get to see its own DNT signal.  For example, if bidder.com is part of exchange.com, the user agent only sees the page request from exchange.com and sends the DNT result for that domain.  If bidder.com has a web-wide exception, they won’t see it in this transaction.  That’s why I recommended we allow bidder.com to assert its own knowledge of the user’s UGE in that case.  Waiting for the actual ad to be served by bidder.com is too late in the transaction flow (and in some cases the ad creative will be served by the Exchange as well so bidder.com will never see their domain’s DNT signal for that transaction).

- - Shane

From: TOUBIANA Vincent [mailto:vtoubiana@cnil.fr]
Sent: Wednesday, October 29, 2014 2:12 PM
To: Shane M Wiley; Jeffrey Chester
Cc: Rob van Eijk; public-tracking@w3.org
Subject: RE: Indirect DNT Processing (Proposed)

Shane,

I believe that's how we designed the "site wide exceptions" to not affect RTB in any way.
At this point we're trying to distort the "no sharing" prohibition to have DNT not impacting in any possible way RTB. I hardly see any difference with a "status quo" since, according to you, everything is already covered by contracts between platforms and bidders.

We provided a couple of examples of how RTB could work. Only one edge case remains  where:
1 No site wide exception has been granted,
2 Bidders need both URL and UID,
3 Actually one of the bidders which has been picked-up by the ad-exchange, also has a UGE.

As I understand, only in that case would your proposal actually bring any value otherwise the answer would simply be "D". This is a very unlikely situation which would only benefit to the few actors which could actually have a web wide exception.

A more balanced solution would be to rely on site-wide exception to support RTB.


Vincent


- -----Original Message-----
From: Shane M Wiley [mailto:wileys@yahoo-inc.com]
Sent: Wed 10/29/2014 7:19 PM
To: Jeffrey Chester
Cc: Rob van Eijk; TOUBIANA Vincent; public-tracking@w3.org (public-tracking@w3.org)
Subject: RE: Indirect DNT Processing (Proposed)

Jeff,



I don't believe I'm suggesting we "prop up" the Exchange marketplace - rather I'm suggesting we understand it and develop a reasonable implementation approach that takes the technical realities into consideration.



- - Shane



From: Jeffrey Chester [mailto:jeff@democraticmedia.org]
Sent: Wednesday, October 29, 2014 10:45 AM
To: Shane M Wiley
Cc: Rob van Eijk; TOUBIANA Vincent; public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: Indirect DNT Processing (Proposed)



Shane:



There is no reason to prop up programmatic, given its dominance and capabilities.  What is required are safeguards-including via DNT.



If the group can't ensure DNT works via the dominant tracking modality, it's a scarlet letter for WC3.



Jeff





Jeffrey Chester

Center for Digital Democracy

1621 Connecticut Ave, NW, Suite 550

Washington, DC 20009

www.democraticmedia.org

www.digitalads.org

202-986-2220



On Oct 29, 2014, at 1:32 PM, Shane M Wiley <wileys@yahoo-inc.com> wrote:





Jeff,



I'm not saying that at all - and I think you know better.  I'm saying we need to find solutions within DNT that support the programmatic marketplace.



- - Shane



From: Jeffrey Chester [mailto:jeff@democraticmedia.org <mailto:jeff@democraticmedia.org> ]
Sent: Wednesday, October 29, 2014 10:15 AM
To: Shane M Wiley
Cc: Rob van Eijk; TOUBIANA Vincent; public-tracking@w3.org (public-tracking@w3.org <mailto:public-tracking@w3.org> )
Subject: Re: Indirect DNT Processing (Proposed)



Is what you and Yahoo saying that DNT shouldn't protect privacy from the widespread and unregulated uses of audience buying/programmatic advertising?  DNT must address programmatic, which is already the majority of the display market and-as we all know-will dominate (even across platforms).



Jeff





Jeffrey Chester

Center for Digital Democracy

1621 Connecticut Ave, NW, Suite 550

Washington, DC 20009

www.democraticmedia.org <http://www.democraticmedia.org/>

www.digitalads.org <http://www.digitalads.org/>

202-986-2220



On Oct 29, 2014, at 12:50 PM, Shane M Wiley <wileys@yahoo-inc.com <mailto:wileys@yahoo-inc.com> > wrote:






Rob,

I'm the Chair of the Metadata Working Group at the IAB so thank you for calling that out.  But understand even that standard will take time to roll out and is meant to compliment - NOT DISRUPT - the current workflow.  The discussions around RTB are highly disruptive and BREAK the current model - with no easily solutions at hand.  That is my core concern - there is a lack of consideration within the group of this critical dynamic.

- - Shane

- -----Original Message-----
From: Rob van Eijk [mailto:rob@blaeu.com <mailto:rob@blaeu.com> ]
Sent: Wednesday, October 29, 2014 9:46 AM
To: Shane M Wiley
Cc: TOUBIANA Vincent; Tracking Protection Working Group
Subject: RE: Indirect DNT Processing (Proposed)

Well, change is a constant factor. For example, the IAB is working on adding metadata all the way down the ad chain. There is no reason why the current protocols are cast in stone. The whole purpose of DNT is to have in impact on current ad practices.
Rob

Shane M Wiley schreef op 2014-10-29 17:06:




Disagree - any new standard should respect the marketplace that it expects to adopt it.  If we force considerable changes in the current ad ecosystem you won't have any adoption (meet in the middle versus force all in one direction).

- -----Original Message-----
From: Rob van Eijk [mailto:rob@blaeu.com <mailto:rob@blaeu.com> ]
Sent: Wednesday, October 29, 2014 6:44 AM
To: Shane M Wiley
Cc: TOUBIANA Vincent; Tracking Protection Working Group
Subject: RE: Indirect DNT Processing (Proposed)

>From what I understand, the URL is an optional field in Bid Requests
in most RTB-protocols. In my view RTB-protocols should innovate to adapt to DNT, not the other way around.
Rob

Shane M Wiley schreef op 2014-10-24 00:33:




Vincent,

Some bidders may only be contextually targeting information (not cross-site or "different context") and will need to the URL to determine content on the page.

- - Shane

FROM: TOUBIANA Vincent [mailto:vtoubiana@cnil.fr <mailto:vtoubiana@cnil.fr> ]
SENT: Thursday, October 23, 2014 3:26 PM
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-complianc <http://www.w3.org/2011/tracking-protection/drafts/tracking-complianc>
e .html#third-party-compliance [1]). 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 <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 <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 <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

Links:
- ------
[1]
http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance <http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance> .
html#third-party-compliance

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

iQEcBAEBAgAGBQJUUnWjAAoJEHMxUy4uXm2JdL8IAJNS/1aJ/eeWxfQLamboPqC1
R2dZXo1+2C5Dm1UkZqynuYKjlzW3XVhZvPk7OUeA8fnGWga9HF0EESW7vDL6pZjf
bmggbHVMyxcvWtM93FLnuzQUbgB7VRUUhlo+dbeqD1YvG6xp0V2qENpnxpm6543t
ro5h9fJPnO/RwRHamtHke9ZY5jRTQ6fQ2PeOegnc5esxfxA4K3vcMb0CAgtVSSoQ
43O1BTOe1VSVJzCAfCEHh+d31EW0/Gvk2PFP/SHjzQrcaKcwrgi/AnLkqa6iIWLA
5t7lB7e0Ferx1suEduyPzaWdQZv8MJz565Kja7GLCsaKUaGK8Dgx1VM0lV/H+eE=
=n25s
-----END PGP SIGNATURE-----

Received on Thursday, 30 October 2014 17:55:37 UTC