RE: [ACTION-20] First parties signaling exceptions to third parties

Peter,

Sorry.  I missed the URI parameter somehow and read it as an additional header.  A URI parameter could work, although I actually think this could be quite complicated since many requests go through multiple services and multiple redirects and the request to the final service likely does not even resemble the original request.  The parameter would have to be passed on.  Cookies would actually have similar challenges, but at least then the communication only needs to happen once - not on every request.  Of course, that does expose the solution to the usual cookie disadvantages, but if the 1st party is storing the exception in a cookie (which is a very likely scenario) then those disadvantages already exist.  

Practically speaking, I do not think we should attempt to enforce a particular methodology, but should allow the participants to choose the method that works best for them (could even be out-of-band visitor id syncing).  Of course, we can still suggest different methods such as these in the docs.

To your point response that the opt/in cookie would have to be per 1st party, I believe that is absolutely correct.  However, that does not seem like a limitation in any way.  It's already a common practice for many 3rd parties to segment their cookie space based on 1st party domain.  And a 3rd party request will almost always know the identity of the containing 1st party either via http_referrer or URL parameter etc.  If exceptions exist (as I am sure they do),  then in those cases, the 3rd party would simply not be able to use the exemption.

-kevin

-----Original Message-----
From: Peter Eckersley [mailto:peter.eckersley@gmail.com] 
Sent: Monday, November 14, 2011 5:54 PM
To: Kevin Smith
Subject: Re: [ACTION-20] First parties signaling exceptions to third parties

I agree that the 1st party has no control over headers, which is why my proposed language was about request parameters.

I'm not deeply opposed to the cookie-based method for 1st/3rd party opt-back-in signaling, but it would be quite hard to get right.  The fact that I'm opting-back-in on nytimes.com, and nytimes embeds tracking-service.com, does not mean that I'm opting back in on tracking-service.com.  So if there was a 3rd party cookie scoped to tracking-service.com it would have to contain or reference a list of applicable 1st parties, and the 3rd party would have to always know which 1st party it was being included by.

Perhaps tracking-service.com could use the domain nytimes.tracking-service.com with a scoped cookie.  But what if the opt-back-in on nytimes.com only applies when the user is logged in, and then the user logs out?

On 10 November 2011 17:06, Kevin Smith <kevsmith@adobe.com> wrote:
>
> For requests like a tracking pixel, the 1st party does not have any control over the headers sent to the 3rd party.  That request is made by the browser.  It's possible that the 1st party could somehow signal to the browser that the existing user has opted back in, then the browser could automatically add the override header, but that seems pretty complicated.  However, my guess is that opt in will often be cookie based, and the communication will happen at opt-in time by the 1st party making a call to the 3rd party allowing the 3rd party to set their own cookies and therefore not need any special communication at subsequent requests.
>
>
>
> From: Peter Eckersley [mailto:peter.eckersley@gmail.com]
> Sent: Wednesday, November 09, 2011 11:20 AM
> To: Tracking Protection Working Group WG
> Subject: [ACTION-20] First parties signaling exceptions to third 
> parties
>
>
>
> Some possible language to consider:
>
> First parties sometimes have active exceptions to DNT.  For instance, 
> a user on the New York Times site may have logged in and knowingly 
> opted back in to being tracked by third parties while reading the New 
> York Times site.  In such a case, the first party needs a way to 
> signal to the third parties that, for these particular requests, an 
> exception is overriding the DNT: 1 header that the user's browser is sending.
>
> If a first party wishes to signal to a third party that there is an 
> active exception to DNT, the first party MUST indicate this with a 
> request parameter "dnt-override=" with a non-null value (eg, 
> "dnt-override=1", "dnt-override=user logged in", "dnt-override=retain 
> for 1 week", etc).  This parameter may be set as a URI query 
> parameter, a URI fragment parameter, or an HTTP POST parameter.
>
> A webserver receiving a request with the "dnt-override=" parameter 
> with a value of "1" MAY disregard a DNT: 1 header that it 
> simultaneously receives from the client.  However if it does so, it 
> MUST send the Tracking: 1 response header to the client.
>
> First parties and third parties MAY agree to additional semantics for 
> values of the dnt-override parameter other than 1 or null.  If a third 
> party receives a value for "dnt-override" where such an agreement and 
> implementation is not in place, it MUST send Tracking: 0 to the 
> client, and ignore the dnt-override parameter.
>
> --
> Peter


--
Peter

Received on Tuesday, 15 November 2011 21:16:52 UTC