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

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

The problem arises because of the difficulty in finding out domain specific data for subrequests. If ad exchange adex.com cannot ascertain the cookies/storage for its list of potential bidders (and relies on a server-server exchange to identify a winning bid) it is driven to leak unique identifiers to the bidders, so the bidders are able to profile or track the user. This is a regulatory risk for all parties.

In the case of cookies there is no technical solution, and this one of the problems with the opt-out cookie approach. The losing bidders have no way to see if they have an opt-out cookie (the ad exchange has sent the UID to them server-server). They either must always take care to discard the UIDs or just to discard them if they lose the bid (and if they win wait to see if they must once the ad is rendered).

But in the DNT system we have the advantage of being able to make the confirmSiteSpecificTrackingException API call. A third-party document/server can determine if one of its subrequests will go out with DNT:0. The DNT:0 can be the result of a) a general preference, b) a site-specific UGE or c) a web-wide UGE.

It is relatively straight forward to create a javascript library that can do this, so the ad exchange can predetermine which bidders it can send UIDs + URLs to.

This does not even have to involve another roundtrip in most cases because a reasonably up-to-date list of subrequest domains with consent can be encoded in a cookie in the adex.com domain. 

DNT helps solve the regulatory risk problem for the ad exchanges and the bidders.

There may be a case to be made to make the confirmSiteSpecificTrackingException easier to use for this use case, because at the moment the library would have to make multiple calls to it. We should discuss that.

Mike





> -----Original Message-----
> From: Rob van Eijk [mailto:rob@blaeu.com]
> Sent: 30 October 2014 22:58
> To: Shane M Wiley
> Cc: TOUBIANA Vincent; Justin Brookman; Nicholas Doty; Tracking Protection
> Working Group; Roy T. Fielding
> Subject: RE: ISSUE-262: guidance regarding server responses and timing
> 
> Shane,
> 
> #1 ok, fair
> #2 It may depend on the use case. A publisher could pass ad information
> to an exchange. The exchange then composes a bid request and send that
> request to several DSP's. This use case is not mere conduit in my view.
> 
> Rob
> 
> Shane M Wiley schreef op 2014-10-30 23:18:
> > Rob,
> >
> > That is incorrect.
> >
> > #1 - The exchange houses the bid transaction but does not set the
> > rules of the bid "winner" - the bid requester sets these rules (but is
> > most often the highest bidder but sometimes quality is selected over
> > bid price).
> > #2 - The exchange houses the bid transaction but does not initiate the
> > request - the bid requester (the inventory supply - typically a
> > publisher or 1st party) actually launches the request and the Exchange
> > forwards the request to those parties interested in bidding (the
> > content demand - typically an advertiser or 3rd party).
> >
> > - Shane
> >
> > -----Original Message-----
> > From: Rob van Eijk [mailto:rob@blaeu.com]
> > Sent: Thursday, October 30, 2014 3:11 PM
> > To: Shane M Wiley
> > Cc: TOUBIANA Vincent; Justin Brookman; Nicholas Doty; Tracking
> > Protection Working Group; Roy T. Fielding
> > Subject: RE: ISSUE-262: guidance regarding server responses and timing
> >
> > Shane,
> > I diagree for two reasons. (1) The key function of the ad exchange is
> > select the highest bidder and (2) the ad exachange initiates the
> > bidding process with a bid requests and therefore initiates the
> > communication with all bidders. These two conditions rule out "mere
> > conduit" in the EU.
> > Rob
> >
> > Shane M Wiley schreef op 2014-10-30 17:50:
> >> Rob,
> >>
> >> Incorrect - they are merely a conduit.
> >>
> >> I don't believe I'm asking for a specific exception for Exchanges but
> >> rather for any Service Provider where the actual transaction recipient
> >> is not visible to the user agent and therefore cannot receive their
> >> appropriate DNT signal for their domain appropriately.  The overriding
> >> rule should be once a party is able to receive their domain's own DNT
> >> signal then they must honor it.
> >>
> >> - Shane
> >>
> >> -----Original Message-----
> >> From: Rob van Eijk [mailto:rob@blaeu.com]
> >> Sent: Thursday, October 30, 2014 2:35 AM
> >> To: TOUBIANA Vincent
> >> Cc: Shane M Wiley; Justin Brookman; Nicholas Doty; Tracking Protection
> >> Working Group; Roy T. Fielding
> >> Subject: RE: ISSUE-262: guidance regarding server responses and timing
> >>
> >> TOUBIANA Vincent schreef op 2014-10-30 10:14:
> >>> 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.
> >>
> >> Precisely, the ad exchange plays a role that goes beyond "mere
> >> conduit".
> >>
> >> Shane M Wiley schreef op 2014-10-29 23:08:
> >>>> As the Exchange is a neutral party I’d recommend we attempt to
> >>>> develop a carve-out/permitted use for this type of entity.
> >>
> >> I object to a permitted use for data exchanges. There are many
> >> different types of exchanges - e.g. private, public, data, etc. - and
> >> new (technical and business)models for exchanges will follow. The Ad
> >> Exchange is - in my view - (jointly) responsible for the ad boundaries
> >> that are used by the bidding algorithms. A permitted use for these
> >> entities is synonymous with 'kicking the can down the road'.
> >>
> >>>> If we create a paradigm such that all members of an Exchange must
> >>>> support DNT, then the Exchange will not support DNT – and as others
> >>>> will likely see this as a competitive disadvantage they will not
> >>>> support it either.
> >>
> >> I am not convinced by the argument, that due to a perceived
> >> competitive disadvantage other Exchanges will not implement either.
> >> The effect could well be that users will shunt exchanges that ignore
> >> DNT, which could turn engineering privacy into the rtb protocol a
> >> competitive advantage.
> >>
> >> Rob
> >>
> >>
> >> TOUBIANA Vincent schreef op 2014-10-30 10:14:
> >>> 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 [1]) 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> 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#T
> >>> S
> >>> V-
> >>> [2]
> >>> <http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#
> >>> T
> >>> SV-
> >>> [2]> ?
> >>>>
> >>>> 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
> >>>
> >>>
> >>>
> >>> Links:
> >>> ------
> >>> [1] https://www.google.com/doubleclick/adxbuyer/guidelines.html
> >>> [2]
> >>> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#T
> >>> S
> >>> V-

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

iQEcBAEBAgAGBQJUUyb1AAoJEHMxUy4uXm2JOc0IANU/NZ6suX9Ti2qwqQddrVId
4y4yKhSYUDj6W549mWNXkGHSCPRj2hetJjqWypg/FYLMXWI5khyLBOn20n9VWEcW
V+aDW4HXeS+4yp/i5+sdPy8/k0KZz0fULktIquHFOREvGYriYK/lxJmNcwFeQuoO
2Q5i5f+oQZ/L+6NNvGWAKC+JEwtoqAI/HkLsGQvZb1/7g4d6lfUUSVJrFirgpzeU
2sbFusjPznf3+Bdys8hEddDN3XvodUptrodndUweKAPIXzL7ha6OGu3I9JROF0pS
n7zjhupH6KEoG1nvTnAKUXH3VMpMpSKFys4jYJbGLTxHLdtvICU6MWbH8WkJhrE=
=SYYy
-----END PGP SIGNATURE-----

Received on Friday, 31 October 2014 06:07:44 UTC