Re: tracking-ISSUE-262: guidance regarding server responses and timing [TPE Last Call]

On Jul 12, 2014, at 7:15 PM, Tracking Protection Working Group Issue Tracker wrote:

> tracking-ISSUE-262: guidance regarding server responses and timing [TPE Last Call]
> 
> http://www.w3.org/2011/tracking-protection/track/issues/262
> 
> Raised by: Nick Doty
> On product: TPE Last Call
> 
> http://lists.w3.org/Archives/Public/public-tracking-comments/2014Jun/att-0019/Rubicon_Project_-_DNT_TPE_Comment_Letter.pdf
> per Vivek, a comment that tracking status values may change depending on when during a real-time bidding process a user requests the tracking status resource.
> 
> 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.

WONTFIX.  A server must respond to any GET request for tracking status,
at any time, and not necessarily corresponding to any specific request
on a designated resource.  In other words, they are independent resources
and the user agent decides when (or if ever) it makes a request for the
tracking status.

Real-time bidding does not have an impact here.  Each time a user agent
is presented with a resource to fetch (i.e., perform a GET on some URI)
it makes a decision whether to request the tracking status or not.
There is no requirement for the UA to do so: the protocol is satisfied by
the DNT preference expressed, so the tracking status resource exists for
the sole purpose of verifying (or finding more information about) compliance.

If the UA chooses not to verify compliance, then no additional requests
will be sent.  If the UA chooses to verify compliance prior to making a
request to a new site, then it will do so after it has been provided the
URI by the real-time bidding algorithm (the URI of the bid winner).
Assuming the bid winner claims to conform to TPE, the tracking status
the UA receives must remain valid for at least 24 hours (or longer if
cache control specifies a specific TTL).   Note that the tracking status
of the bid winner is separate from the tracking status of the bidding
process if they are separate HTTP requests; if the market acts as a
gateway and provides the bid winning response itself, then the market
is responsible for the tracking status of itself and all downstream
recipients (those it shared the request data with).

Our expectation is that only a very small number of user agents will
actively verify compliance and will only do so once per site.  Some
UAs might rely on others to verify compliance, or limit such checks
to sites that have a bad reputation.

....Roy

Received on Wednesday, 27 August 2014 02:40:39 UTC