W3C home > Mailing lists > Public > public-tracking@w3.org > February 2012

RE: ACTION-98: Bring input on ISSUE-111 to the group; otherwise it's closed

From: Shane Wiley <wileys@yahoo-inc.com>
Date: Tue, 21 Feb 2012 20:03:55 -0800
To: Nicholas Doty <npdoty@w3.org>, Matthias Schunter <mts@zurich.ibm.com>
CC: Tracking Protection Working Group WG <public-tracking@w3.org>
Message-ID: <63294A1959410048A33AEE161379C8023D0CAFF66D@SP2-EX07VS02.ds.corp.yahoo.com>

I disagree as this will require polling for site-specific exceptions when it's not necessary (several use cases brought up by the working group where DNT:2 solves similar issues).  Why are you against a browser sending a 1st party the DNT:2 message when that party has site-specific exceptions recorded for their domain?  As browsers will be broadcasting a DNT value (if one exists), then it appears to be better for publishers if a DNT:2 message is sent in those cases where it's appropriate (versus receiving a DNT:1 value and then needing to poll every single time to see if exceptions exist).

I'm hopeful either companies that build web browser or publishers can provide their view points on this issue as we're the entities impacted by the outcome here.

Thank you,
- Shane

From: Nicholas Doty [mailto:npdoty@w3.org]
Sent: Tuesday, February 21, 2012 7:57 PM
To: Shane Wiley; Matthias Schunter
Cc: Tracking Protection Working Group WG
Subject: Re: ACTION-98: Bring input on ISSUE-111 to the group; otherwise it's closed

Sorry, I missed this message during the post-Brussels travel. Matthias proposes we close this because of the response discussion, but I think this is actually an issue about the request header rather than the response header/tracking response status.

I would propose an alternate to Shane's text below, that we remain with just DNT:0 and DNT:1. (I believe the current draft text would satisfy this.)

Publishers may determine whether site-specific exceptions are available for their site via the JavaScript API defined in Section 6. User agents may not know on initiating a request whether any site-specific exceptions will apply, for example. Publishers can use client-side JavaScript to check the DNT value, check for the presence of functionality to request site-specific tracking exceptions and call client-side methods to confirm exceptions. Users and their agents need not broadcast the possible presence of an exception with every HTTP request.


On Jan 30, 2012, at 8:42 PM, Shane Wiley wrote:

Should the user agent send a different DNT value to a first party site if there exist site-specific exceptions for that first party? (e.g. DNT:2 implies "I have Do Not Track enabled but grant permissions to some third parties while browsing this domain", DNT:3 implies "I grant you a web-wide tracking exception")

To better arm Publishers with the ability to distinguish between users who have a general DNT signal activated (DNT:1) and those who have also provided for a Site Specific Exception for their site, it would helpful for a different signal to be provided in the later case.  This approach will help reduce site-specific exception list queries, as well as, allow for a cleaner site-specific exception process on "first use" scenarios.

Where available, User Agents SHOULD provide 1st parties with a distinguishing signal to alert them that Site-Specific Exceptions exist for the 1st party.  If a User Agent supports this functionality, it must reply with a DNT:2 signal when appropriate.
Received on Wednesday, 22 February 2012 04:04:34 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:44:45 UTC