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

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 woul 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.

Received on Sunday, 13 July 2014 02:15:41 UTC