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

Tom said:
>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.

This I strongly disagree with.  I am certainly not opposed to a solution in which the browser "controls" all or some aspects of the DNT interactions, but that is *not* the point of our endeavors nor is it mission critical to success.  Mission critical is that 1st and 3rd parties know when and what they can track and what they can do with the collected data.  Communication back to the user is a nice addendum that I think most of us agree should be in there, but this still does not necessarily mandate browser control.  Obviously browsers will play a big role in most areas of DNT implementation.  However it is not practical to try to make the browser the sole governing agent because among other things, that limits future technical adoption of non-browser based technologies and much of the shared data is not currently done through the browser (ie - out of band syncing).  Again, I am not arguing against browser control, I am arguing against saying a browser *must* be able to control the interaction.


-----Original Message-----
From: Tom Lowenthal [mailto:tom@mozilla.com] 
Sent: Tuesday, November 15, 2011 1:07 PM
To: public-tracking@w3.org
Subject: 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
>>
> 
>

Received on Tuesday, 15 November 2011 21:18:36 UTC