RE: Indirect DNT Processing (Proposed)

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

Shane,

You gave short shrift to 2 suggestions from the group on how to help with RTB, transitive UGEs (so exchanges get purpose limited consent) and naked UID sharing (so previously registered consent can be actioned) , both with a deal of thought behind them. What other solutions should we discuss, exchanges just get to ignore DNT?

Mike

> -----Original Message-----
> From: Shane M Wiley [mailto:wileys@yahoo-inc.com]
> Sent: 29 October 2014 16:51
> To: rob@blaeu.com
> Cc: TOUBIANA Vincent; Tracking Protection Working Group
> Subject: RE: Indirect DNT Processing (Proposed)
> 
> 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]
> 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]
> > 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]
> >>  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
> >> 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]
> >>  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
> >>
> >> Links:
> >> ------
> >> [1]
> >> 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

iQEcBAEBAgAGBQJUUSb3AAoJEHMxUy4uXm2Jw14H/jI9kEVdJgXAWzAieoWYVCjI
zDfuvIfS92cUQn+fcMQW2tLy2/FcdMf/S0nDkpiOhhR1NmEBD9hxoeaD+OYFqvYe
DLcgsnJ0UGvbRy25PupfSBIyi+2PH0zFs3K/ZueV7PTkXLgT9PJLIRifXGI28aSy
NLKVMw7N2anTTH0IBjoocmeGkoqVKegy1mG8ONZJxjBfZkgjlGAtd5bMwTPB2nMz
GA63tg0H8ltV5w23/e5gkpKBRBjGca2/0Og13EVXQ7MmqVFgwfXyf3OCWbvPSv2p
o7wOjfBWQlcSz8EDgu7c/Cs0lRYu+IAHDUi60Qyvud4Y+2YJ8sqvECsDt4MUCII=
=7Gif
-----END PGP SIGNATURE-----

Received on Wednesday, 29 October 2014 17:43:07 UTC