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


If each of the third party was directly interacting with the UA, the UA would be able:
- Be informed of the status of all the recipient based on previous interaction and eventually block a given transaction,
- Verify that it can confirm each WebWideException that is claimed by a given party,
- Be informed in advance of how many third parties are collecting data about him,

An additional issue with this proposal is that the UA only have information about the winning bidders (i.e. final recipient) it might be that all the other bidders disregarded the DNT signal and the UA would still not be informed of that.


-------- Message d'origine--------
De: Shane M Wiley []
Date: ven. 31/10/2014 20:49
À: Mike O'Neill; 'Roy T. Fielding'
Cc: 'Tracking Protection Working Group'
Objet : Re: ISSUE-262: guidance regarding server responses and timing
The list of "possible" bidders is too large to store in a cookie reliably - and you'd be adding the overhead of maintaining that list over time so you'd need to determine points in time to update the list - both of which would add significant weight to transactions.
If each of the 3rd parties was interacting with the UA directly - they'd each receive their Cookie ID and URL directly.  Why is placing a Service Provider in front of that reality changing the rules?  A SP inherits the rules of the party it represents - in this case the 3rd parties bidding on that ad placement requested by the publisher.
I like Roy's idea of adding a specific TSR for this situation and allow the 3rd party to directly communicate with the user agent if they win the bid and serve the ad directly.
- Shane Shane Wiley
VP, Privacy & Data Governance
      From: Mike O'Neill <>
 To: 'Roy T. Fielding' <> 
Cc: 'Tracking Protection Working Group' <> 
 Sent: Friday, October 31, 2014 11:13 AM
 Subject: RE: ISSUE-262: guidance regarding server responses and timing
Hash: SHA1

Roy, there need not be any introduced latency. On the very first rendering of it can encode the list into a cookie, which will be immediately available in the next request to it. The list can only be third-parties it has a service provider relationship with, which we could ask Shane, but I would have thought unlikely to be more than low hundreds. Given the current cookie load on the average publishers website I don't think this would be much of an extra burden. It could be Huffman coded or something anyway. The list would need to be updated in the script context, but only the initial value would be actioned (to minimise latency). 

The problem with passing on DNT is that it can only see the general preference (which might even not be there, remember DNT:0 is not contingent on it), or its own UGE. It must use confirmSSTE to know what to pass to each of its bidders. If it knows which ones do not have DNT:0 (or maybe in the US those that have DNT:1), it knows which it can send UIDs to.


> -----Original Message-----
> From: Roy T. Fielding []
> Sent: 31 October 2014 17:39
> To: Mike O'Neill
> Cc: Tracking Protection Working Group
> Subject: Re: ISSUE-262: guidance regarding server responses and timing
> On Oct 30, 2014, at 11:06 PM, Mike O'Neill wrote:
> > Hash: SHA1
> >
> > The problem arises because of the difficulty in finding out domain specific data
> for subrequests. If ad exchange 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 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
> I think the additional latency required by such a procedure would not
> be feasible in the ad exchange use case, nor is it likely to be reliable
> given that the exchange itself doesn't know the current set of bidders
> until after they start bidding.
> I think we need to step back and consider the problem in general.
> We have a server that wants to support DNT but is, in fact, relaying
> the request to others.  This is a 1:N gateway.  It is not too late for
> us to introduce a TSV that says "I am a 1:N gateway, here is information
> about me and here is information about my requirements on downstream
> recipients; I promise to relay the DNT signal to those recipients and
> will relay the final recipient's Tk response to the current request."
> We can use a TSV of X for that and give it both protocol and compliance
> requirements.
> ....Roy
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.3.26.5094 -
Charset: utf-8



Received on Friday, 31 October 2014 20:21:25 UTC