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

Vincent,
The 1:M nature of the transaction does create challenges but it is still a Service Provider and should be treated as such.  I believe Roy's solution still solves for the transparency issue but wouldn't help with the UA validation elements as the bid loser would not interact with the UA on that transaction.  Note those parties WILL interact with that user agent again so they can confirm the bidder's DNT assertion at that time (and the bidder would need to store the result until the next interaction).  Its only this stored result that I'm asking a bidder be able to leverage in cases where they aren't able to communicate with the UA directly.
- Shane Shane Wiley
VP, Privacy & Data Governance
Yahoo
      From: TOUBIANA Vincent <vtoubiana@cnil.fr>
 To: Shane M Wiley <wileys@yahoo-inc.com>; Mike O'Neill <michael.oneill@baycloud.com>; Roy T. Fielding <fielding@gbiv.com> 
Cc: Tracking Protection Working Group <public-tracking@w3.org> 
 Sent: Friday, October 31, 2014 1:20 PM
 Subject: RE : ISSUE-262: guidance regarding server responses and timing
   
 RE : ISSUE-262: guidance regarding server responses and timingShane,

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.

Vincent




-------- Message d'origine--------
De: Shane M Wiley [mailto:wileys@yahoo-inc.com]
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

Mike,
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
Yahoo
      From: Mike O'Neill <michael.oneill@baycloud.com>
 To: 'Roy T. Fielding' <fielding@gbiv.com>
Cc: 'Tracking Protection Working Group' <public-tracking@w3.org>
 Sent: Friday, October 31, 2014 11:13 AM
 Subject: RE: ISSUE-262: guidance regarding server responses and timing
  
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roy, there need not be any introduced latency. On the very first rendering of adex.com 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 adex.com script context, but only the initial value would be actioned (to minimise latency).

The problem with adex.com 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.

Mike



> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@gbiv.com]
> 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:
>
> > -----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJUU9FOAAoJEHMxUy4uXm2JC4kH/i00XhsXKXjENV6yLZQtUHas
hmax7J/y2UTg5E18/wkQyXiCelDe2rikL+ShBWp5BFT2PXVkzGTLmrmE2P0TDqOQ
UqmFQpqbydD98RzcOcSmr0a0cvNaBpYWt07GRKTJe+pqf9lcXoKtn4KC4dEYaaCN
36GZ3LVqG4ZwuQTJFEjJVTKFYkOitB21K8S2D2U7rA4YCZvFmuwrRriV9U25yLoN
ll8rcMMDFVA16A9N0koGqg4FJsNaWkPgU/Hj16l529g8t2GOQiY+wm/7scJRhDTW
rSKf2slFqi2gb5f+q4s7WVPfm1qn/q5FpdirF6pnacLDgmnWIq4vzcq8dyS+ivw=
=k124
-----END PGP SIGNATURE-----