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

I absolutely agree and Rob’s pricing recommendation is on target (perhaps poor metaphor!).  I hope we can see movement here.


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 4:38 PM, Rob van Eijk <rob@blaeu.com> wrote:

> Let me give another possible way to go.
> 
> From a privacy engineering point of view, we should aim for making DNT fit for purpose. We will see (more) examples of automated real time auctions, intended to analyze or predict the personality or certain personal aspects relating to a natural person, including the analysis and prediction of the person’s health, economic situation, information on political or philosophical beliefs , performance at work, leisure, personal preferences or interests, details and patterns on behavior, detailed location or movements.
> 
> Therefore, the current rtb model needs to take both easy opt-out and (explicit) opt-in protocol requirements into account. This holds for the ad exchange, but also for ssp's and dsp's. The key reason is that DNT will effect the price. Dsp's crafting the bids should have knowledge of the DNT value associated with the deal. DNT info should come with the bid request. Such requirments could be expressed normatively in the TCS.
> 
> If this can not be done in a technical way, another option is to hold the exchange accountable and responsible for it's bidders. Any bidding party not honoring DNT should not get access to bid requests associated with UID's from users with DNT:1. Such requirments could be expressed normatively in the TCS.
> 
> Rob
> 
> 
> Shane M Wiley schreef op 2014-10-29 21:29:
>> Perhaps that's the way to go here - provide an exception for a Service
>> Provider (already a 3rd party) to pass data through to another 3rd
>> party only for assessment purposes - then immediate destruction or
>> de-identification.
>> - Shane
>> -----Original Message-----
>> From: Mike O'Neill [mailto:michael.oneill@baycloud.com]
>> Sent: Wednesday, October 29, 2014 1:18 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
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> Shane, if you mean short-term use, that can not apply to data shared
>> with third-parties. The relevant text is:
>> It is outside the scope of this specification to control short-term,
>> transient collection and use of data, so long as the data is not
>> shared with a third party and is not used to build a profile about a
>> user or otherwise alter an individual user’s user experience outside
>> the current network interaction. For example, the contextual
>> customization of ads shown as part of the same network interaction is
>> not restricted by a DNT:1 signal.
>> Otherwise exchanges would need some new kind of permitted use (or consent).
>> Mike
>>> -----Original Message-----
>>> From: Shane M Wiley [mailto:wileys@yahoo-inc.com]
>>> Sent: 29 October 2014 20:02
>>> To: Mike O'Neill; 'Justin Brookman'; 'Nicholas Doty'
>>> Cc: 'Tracking Protection Working Group'; 'Roy T. Fielding'
>>> Subject: RE: ISSUE-262: guidance regarding server responses and timing
>>> Mike,
>>> The Exchange would not be engaged in cross-site tracking if the data
>>> was used for assessment purposes only and then immediately purged or de-identified.
>>> - Shane
>>> -----Original Message-----
>>> From: Mike O'Neill [mailto:michael.oneill@baycloud.com]
>>> Sent: Wednesday, October 29, 2014 12:50 PM
>>> To: 'Justin Brookman'; 'Nicholas Doty'
>>> Cc: 'Tracking Protection Working Group'; 'Roy T. Fielding'
>>> Subject: RE: ISSUE-262: guidance regarding server responses and timing
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>> Justin,
>>> The ad exchange cannot share DNT:1 browser ID with another party
>>> unless
>>> either:
>>> a) it knows the other party has consent for this browser i.e. by that
>>> fact being communicated to it when consent was given to the other
>>> party (transitive UGE), or
>>> b) it only passes the UID without any other kind of data i.e. it is
>>> passing a unique key which can have no meaning other than to a party
>>> that has already been given consent (naked UID).
>>> In both cases it would have to be a service provider for the
>>> downstream parties (and also the first-party IMO).
>>> If it did pass IDs with data it would be enabling/indulging in
>>> cross-context tracking (with DNT set).
>>> Mike
>>> > -----Original Message-----
>>> > From: Justin Brookman [mailto:jbrookman@cdt.org]
>>> > Sent: 29 October 2014 18:57
>>> > To: Nicholas Doty
>>> > Cc: Tracking Protection Working Group; Roy T. Fielding
>>> > Subject: Re: ISSUE-262: guidance regarding server responses and
>>> > timing
>>> >
>>> > I’m not sure I understand how this would work in practice for the
>>> > losing
>>> bidders.
>>> > Presumably when the bid goes out, each bid recipient is able to
>>> > identify the unique browser (through matching to Exchange ID?) in
>>> > order to determine if it information with which to target the ad.
>>> >
>>> > First, does TPE require the exchange to pass on a DNT:1 request to
>>> > bidders and other third parties? Should that be required as a
>>> > condition of sending the dynamic ? response?
>>> >
>>> > As I read this proposal, even if the DNT:1 request is passed on,
>>> > bidders would not be required to honor (unless the exchange’s rules
>>> > or local law required it) and there would be no way for a losing
>>> > bidder to signal back to the user that it would not add information
>>> > about the lost bid to a user’s profile. Though if that party ever
>>> > wanted to serve an ad based on that data to a DNT:1 user, it would
>>> > have to acknowledge
>>> that it engages in tracking in the TSV, right?
>>> >
>>> > Also, I believe Shane indicated on a previous call that losing
>>> > bidders are typically prohibited from retaining (or using?) lost bid data.
>>> >
>>> > 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 . . .
>>> >
>>> > Apologies if these questions are wildly off the mark; I am still
>>> > trying to wrap my head around this thorny issue.
>>> >
>>> > 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#TSV-?
>>> > >
>>> > > 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
>>> >
>>> >
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.13 (MingW32)
>>> Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
>>> Charset: utf-8
>>> iQEcBAEBAgAGBQJUUUTiAAoJEHMxUy4uXm2JxrEH/0sl6aPmRmIaPHDCesiN84s
>>> m
>>> S5Ii3MQILVaZfvGGpHvci4Em4ekdxQfCHelZIot5rXLnmg3xWPdU3ggg7OFP67RY
>>> Gw0zxF1wz/48HyMLT1zoxTuyLryaorjwzcOFiW70dwO9JJgYzaeDQFn6CkIPQ25s
>>> xUeFjaT2SWTq5x8571MtJQHk3dGolfYK8n8KOm/7HGEl0Zjki5of4p17y8EDwmvx
>>> 5lgvnocJX6dOZgcRTBdjUBuy+Y//3yMt2FkVHRh/CQDTBNfwcTwMsWdPE4Vkkllf
>>> vtcDkLLItNoVxTb+RpMV81xGlEZw5YuuOhNNseBf4+BOTCUMv7bR4Dt7PN5SgHY
>>> =
>>> =2EF9
>>> -----END PGP SIGNATURE-----
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.13 (MingW32)
>> Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
>> Charset: utf-8
>> iQEcBAEBAgAGBQJUUUuAAAoJEHMxUy4uXm2JSeYH/0tQr9I090uzuGJZD644nlGf
>> hdNQ+32LuE6wIDiXr7optMfn7ZJ3LLexGbwKyNnfqbakYlbJXjzUksNyUFO9JQz3
>> 5LM03D4BBLalsVIRq6+KhH4KtNRCaC44hxfHnWWJB3c+8CWcvgTbBjaVaHOiTmBj
>> Y04uHsW13Q9XJnSjODaw25JuJH5P4u/B7zn3jbtfxqJqVyXr3Mq56abbatPryM/Z
>> 7mUKXsV/uBzZcgqL5g0sEgAqP9zSUfkHx16Qacms4L9eC0y+vTd+TjW5NZA7hfQ3
>> 1ac67jwsRLaSEt6kQzUHlLhFwjhxs4eOnLam8RD07DGp2XRq/eF13hlWTvtbPa8=
>> =blrr
>> -----END PGP SIGNATURE-----
> 
>