W3C home > Mailing lists > Public > public-tracking@w3.org > December 2014

Re: Indirect DNT Processing (Proposed)

From: Justin Brookman <jbrookman@cdt.org>
Date: Wed, 10 Dec 2014 17:21:59 -0500
Cc: Tracking Protection Working Group <public-tracking@w3.org>
Message-Id: <00BA6A02-E634-4203-88C1-F54A58CEF3D3@cdt.org>
To: David Singer <singer@apple.com>

On Dec 10, 2014, at 12:34 PM, David Singer <singer@apple.com> wrote:

> The three questions I asked on the call:
> 
> 1. Why is the ‘consistent report’ only for tracking status N?

As I understand it, this is because the gateway and the losers aren’t allowed to track at all under this model.  There would be no point in responding with a ecosystem-wide T because only the winner is allowed to track, and the winner has to separately return its answer.  On the other hand, if the ecosystem is allowed to retain tracking data (intermediary or losers), this would require an initial value of T (and a corresponding link to a compliance policy explaining what’s up); I just don’t think that this proposal would consider that a neutral “gateway."

> 2. Does this address any tracking behavior by the Gateway itself?  Is it clear what the gateway has to do if it tracks?

I think Roy said on the call that the gateway has to operate as a “service provider,” and therefore can’t do any tracking of its own accord.  Shane has often referred to the gateways as effectively service providers, but I’m not sure that they will typically meet the standard’s formal definition (though this definition only appears in TCS, it’s not currently in TPE).

> 3. How does this interact with Exceptions? Perhaps some clarifying notes are in order?

Right, this we discussed on the call, and I’m not entirely sure I understand the answer.  I also don’t understand how Roy’s proposal intersects with Shane’s separate proposal to allow servers to use cached information about a UGE in order to claim an exception.  I know Nick had some concerns about this proposal, but I don’t know if Roy’s proposal was meant to address this issue (or reject it by not including).

Either way, I imagine a winning bidder who has consent should respond with a C in the Tk header field, yes?  It sounds like losers wouldn’t be able to retain even if they have consent to track (though not sure that’s much different than how RTB operates today).  It also sounds like the gateway couldn’t collect tracking data even if it had consent; again, not sure how different that is from today if they really are effectively service providers.

> 
> Otherwise this seems right to me.
> 
> I think Roy addressed these in the call.
> 
>> On Dec 5, 2014, at 11:29 , Roy T. Fielding <fielding@gbiv.com> wrote:
>> 
>> This is ISSUE-262 ...
>> 
>> I have further clarified the requirements to be on the gateway and
>> added a requirement that the gateway have reason to believe that
>> the non-selected recipients will not retain tracking data.
>> 
>> I made some other editorial improvements that messed up a diff, so
>> below is just the relevant text of
>> 
>> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#TSV-G
>> 
>> ....Roy
>> =============
>> 6.2.4 Gateway (G)
>> 
>> A tracking status value of G means the origin server is acting as a gateway to an exchange involving multiple parties. This might occur if a response to the designated resource involves an automated selection process, such as dynamic bidding, where the party that is selected determines how the request data will be treated with respect to an expressed tracking preference. Similar to the ? value, the G TSV indicates that the actual tracking status is dynamic and will be provided in the response message's Tk header field, presumably using information forwarded from the selected party.
>> 
>> This tracking status value is only valid as a site-wide status. An origin server MUST NOT send G as the tracking status value in a Tk header field or within the representation of a request-specific tracking status resource.
>> 
>> A gateway MUST NOT send G as the tracking status value if it knows in advance that all of the potential recipients have agreed on a single tracking status value of N (not tracking); in this case, the gateway MUST respond with N instead of G.
>> 
>> A gateway MUST NOT send G as the tracking status value unless it has reason to believe that recipients other than the selected party will not retain tracking data after the selection has been made when the expressed tracking preference is DNT:1; if non-selected recipients retain tracking data under DNT:1, the gateway MUST respond with T instead of G.
>> 
>> If G is present in the site-wide tracking status:
>> 
>> • the gateway MUST meet the requirements of a service provider for each of the parties to which it provides request data;
>> • the gateway MUST send a link within its site-wide tracking status representation to a privacy policy that explains what limitations are placed on parties that might receive data via that gateway;
>> • the gateway MUST forward any expressed tracking preference in the request to each party that receives data from that request; and,
>> • the gateway MUST send a Tk header field in responses to requests on the designated resource and include within that field's value a status-id specific to the selected party, such that information about the selected party can be obtained via the request-specific tracking status resource (see section 6.4.2 Request-specific Tracking Status).
>> 
>> =============
> 
> David Singer
> Manager, Software Standards, Apple Inc.
> 
> 
Received on Wednesday, 10 December 2014 22:22:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:40:15 UTC