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

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

The web-wide confirm might work for this but the TPE is ambiguous. Currently it applies only to the document-origin (in this case adex.com because it will execute in a frame pointing to adex.com), unless you supply a domain property in the ConfirmExceptionPropertyBag. This property is not defined for the confirm but, if it is assumed to be under the same "cookie-like" rules as the request, can only be used for subdomains of adex.com.

The TPE needs to be clarified on this anyway, but it might be better to change it so it can receive an array of targets like the site-specific confirm.

There is a fingerprinting risk, but that is what is happening in this use-case anyway.

Another way is to assume the site-specific confirm checks for web-wide grants, which just needs a minor change to the description. A web-wide exception would override a site-specific one anyway, and there is no way to tell them apart at the server. If a site needs to check for consent for one of its embedded resources, say adex.com, it does not care whether the exception was due to a web-wide grant or a site-specific one. We could then retire the web-wide confirm as it would be redundant.

Mike  



> -----Original Message-----
> From: TOUBIANA Vincent [mailto:vtoubiana@cnil.fr]
> Sent: 04 November 2014 10:36
> To: Nicholas Doty; Tracking Protection Working Group
> Subject: RE: ISSUE-262: guidance regarding server responses and timing
> 
> Nick,
> 
> I believe we've been trying to identify which is the party in capacity to  respond
> to the DNT request. The problem is, the bid winner is not in capacity to do so
> because it is unaware of who had accessed to the data and therefore cannot
> guarantee that data has not been shared with parties not having been granted
> web-wide exceptions.
> 
> The clean technical solution to handle that would be for the first recipient of the
> message to check for site wide exceptions for all parties receiving data
> downstream so it will be able to respond appropriately to the DNT signal (along
> the line of what Mike proposed I guess).
> 
> Normative text:
> For Servers in direct communication with the User Agent that then communicate
> further with other parties within the same transaction but outside direct
> communication with the User Agent, those Servers MAY send a temporary "?"
> response and MUST call confirmWebWideException to check existing exception
> for all downstream parties receiving the data in order to determine if tracking
> outside exceptions occurs. The server MUST provide a final response to the DNT
> request during the transaction.
> 
> Vincent
> 
> -----Message d'origine-----
> De : Nicholas Doty [mailto:npdoty@w3.org]
> Envoyé : mardi 4 novembre 2014 04:52
> À : Tracking Protection Working Group
> Objet : Re: ISSUE-262: guidance regarding server responses and timing
> 
> I feel we've let this thread get rather a long ways off of the original topic. ISSUE-
> 262 is an issue raised as a Last Call comment to the TPE specification, regarding
> the timing of server responses in cases of ad exchanges or other cases where
> server-to-server communication takes place.
> 
> > Accordingly, Rubicon Project requests that the Working Group include some
> guidance as to how responding servers should deal with such timing issues.
> https://www.w3.org/2011/tracking-protection/track/issues/262
> 
> I believe we can address this with the existing "?" tracking status value (for use in
> pre-fetching) and some clarity about Tk header responses being valid only for
> the request in question. Regarding next steps: we can follow up with the
> commenter to see if that explanation makes sense to them. We could also
> consider an editorial note or example in the TPE specification, if we expect this
> to be a common confusion for implementers.
> 
> TPE doesn't require any compliance determinations, but just a response to the
> question of how to make a response available when different downstream
> servers are involved. There seems to be some interesting discussion about the
> different possible models and how that would apply to DNT compliance (as
> described in the separate Tracking Compliance specification) and our definition
> of service provider. If someone has a text proposal for changes to the
> Compliance editor's draft (or even just a concrete description of the problem
> you see, so that someone else can draft a change proposal) we could continue
> that discussion with a different issue number.
> 
> 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

iQEcBAEBAgAGBQJUWQA2AAoJEHMxUy4uXm2JDR4H+wR9xwXwVBYd8EzVifuuTvLq
CSJq3W/8SywIJwi5G9GoTqAdgMmWlk8fxVuQv5AYZE2Mrx4LDhZ1gvJAKzYiioEA
MukdBbdwHNWaSZlL0WPJYoyYygxJxgYPEsQgMPeiyuURdvQBwAZCkErFzYzPPDC5
cmkGRt899KQJN4DCZd8PBQQwxzkduBQR0otMul8Knsh9x6nD6DAUBuCeBZQpHWHS
ceCygl60IE+eHs9UUsw4baDFC1c4MaHZHNH8XLqskNai9XyM/32OHyIpvSMxnF45
9dkdPphSkPm+Q9BQuf5g2y509uvEe4GoxvZ7ZA8+RCpVhYMK+66H3tt4CKRRDzs=
=V8Dv
-----END PGP SIGNATURE-----

Received on Tuesday, 4 November 2014 16:36:17 UTC