Privacy/TPWG/Change Proposal Regarding gateways and exchanges
ISSUE-262 guidance regarding server responses and timing
This page is to collect potential TPE changes to address the tracking status responses from gateways, ad exchanges or other servers that facilitate downstream communication. In particular, see this Last Call comment about tracking status resources and timing:
- The TPE does not provide any guidance as to when a server must respond to a valid GET request for tracking status. Timing may not matter for many parties in the ecosystem, but it is particularly important for third parties like Rubicon Project that operate or use automated exchanges that allow real-time bidding. Because only a bid winner can adequately respond to the GET request, the specific tracking status resource (“TSR”) response will change depending on whether the GET request is sent immediately upon loading a page (i.e., before bidding on an impression is complete), or instead is sent after bidding is complete and the winner is determined. Rubicon Project is concerned that such a system could actually increase end user confusion and uncertainty, by providing different responses at different times. To the extent that user agents, plug-ins, or add-ons rely on the TSR to inform the an end user of a responding server’s tracking practices, the fact that the content of the notice to the end user would change depending on the timing of the request could undermine consumer confidence in the DNT mechanism and actually cause consumer confusion. Accordingly, Rubicon Project requests that the Working Group include some guidance as to how responding servers should deal with such timing issues.
'G' response value
Commit 1.274 Commit 1.275 from Fielding
See G status value section of Editor's Draft.
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).
Indirect processing of DNT consent
Vincent proposal regarding G status value
For Servers in direct communication with the User Agent that then communicate further with other parties within the same interaction but outside direct communication with the User Agent:
- If they share tracking data about the interaction those servers SHOULD send a "G" response
- If they do not share tracking data about the interaction those servers SHOULD send a "N" response.