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

In this situation, the browser *does* have control of the headers sent
to the third party. The first party doesn't control the header, but it
does control the request parameter.

It seems that the whole point of Peter's proposal is to constrain the
communication between first and third parties, so that the opt-in
communication *must* happen in a way that the browser can recognize, and
-- more importantly -- control.

On 11/13/2011 10:10 AM, Rob van Eijk wrote:
> The whole idea of developing a DNT protocol that will be handled by the
> browser, is that it may superseed the same-origin on which current
> header behavior is based. That is part of the out of the box thinking
> exercise. For requests like a tracking pices, the browser should have
> control over the headers sent to the 3rd party.
> 
> -- 
> Rob
> 
> On 11-11-2011 2:06, Kevin Smith wrote:
>>
>> For requests like a tracking pixel, the 1^st party does not have any
>> control over the headers sent to the 3^rd party.  That request is made
>> by the browser.  It's possible that the 1^st 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 1^st party making a call to the 3^rd party allowing the 3^rd 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
>>
> 
>