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

On Oct 30, 2014, at 11:06 PM, Mike O'Neill wrote:

> -----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

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

Received on Friday, 31 October 2014 17:39:00 UTC