RE: Status of ISSUE-143

Justin,

Thank you for the detailed email.

History:  I disagree on the "agreements" that have centered around the steps discussed below.  While I agree on the closing of TPE Issue-143 as a temporary position in consolidating tickets - in this case to TCS Issue-194 - we did this with the express agreement to revisit this in the TPE once the topic had been handled in the TCS.  Two conflating situations: the Swire/W3C June Draft and the cessation of effort on the TCS, caused this critical issues to be lost in the shuffle.  I was in Sunnyvale and we most certainly did NOT agree on this topic and simply agreed to continue the conversation (this was ahead of the TCS "pause").  I've reviewed this with several other consistent TPWG participants and they agree.

Net new information to consider:  The only significant push back this request received was the increased page request header size that would result in "byte bloat" across the Internet.   After further discussion within industry I want to push back on that position and alter the language requested to help strengthen this perspective.  First, only those headers coming with DNT:1 would need to include this conditional field.  Second, only in those situations where the DNT:1 setter is something other than the current User Agent (already conveyed in the UA String) would this information be added.  If a 3rd party tool communicates its setting through the UA in a manner that the UA has validated, then this is not necessary (but nice-to-have so becomes a "MAY" in those cases).  Lastly, we believe less than 12 bytes on average would ever be used (simply include the domain/suffix of the setting party's site).  This layering of conditions places the percent volume increased much lower than originally discussed and those of us on the Server implementation side believe this is a critical enough issue to justify this additional byte load on the transaction.

Draft language addition to TPE:  (Section 4.2)

Option A:  Delimit the DNT-field-value with an optional element, or
Option B:  Introduce an additional DNT-field-name = "DNTSET"

[Roy, I've been reviewing recent RFCs and have seen both approaches taken - is there a preferred approach?]

<new text - normative>
A user agent must send the DNTSET element only in cases where the DNT field-value is set to "1" (%x31) and the setter is not equal to the party provided in the HTTP "User-Agent" string for the network interaction.  In cases where the setter has been validated as part of the user agent's DNT approach this is not required but the setter may optionally pass the DNTSET field for greater transparency.  The DNTSET element should reflect the setter's parent HTTP domain.  The value should consist of valid URL characters and not exceed 30 characters.
</new text>

<new text - non-normative>
EXAMPLE 2
GET /something/here HTTP/1.1
Host: example.com
DNT: 1
DNTSET: privacytool.org
</new text>

I'm hopeful we can appropriately consider this ahead of moving to Last Call as this is a long-standing issue that has been repeatedly brought up through-out this process only to be side-stepped at the very last moments in one of the rare occasions I've not been able to participate in our weekly call.

If you disagree, could one of the W3C staff share the Formal Objection process details and we'll submit that immediately.

Thank you,
- Shane

From: Justin Brookman [mailto:jbrookman@cdt.org]
Sent: Wednesday, February 19, 2014 6:10 PM
To: W3C DNT Working Group Mailing List
Subject: Status of ISSUE-143

On the working group call on January 29th, Shane Wiley asked whether we were planning to address ISSUE-143<http://www.w3.org/2011/tracking-protection/track/issues/143> before proceeding to last call on TPE.  On the following week's call, the Chairs responded that discussion on this issue had been closed after the Sunnyvale face-to-face; however Shane was traveling and missed the discussion.  Last week, Shane expressed disagreement with the decision not to reopen  ISSUE-143 prior to Last Call, and asked me to send out an email documenting our decision.

So a brief summary of the issue:  Shane had originally raised this issue in 2012 to propose that user agents that send a DNT header should also include a data element in the header identifying what software purports to have the user's consent to send the signal.  The proposal was predicated upon concern that a diverse and unaccountable ecosystem of intermediaries could be setting DNT signals without a user's permission.   As Shane stated:

This way [under this proposal], if industry feels a party is inappropriately setting a tracking preference, we can take steps to discover which headers are coming from this party and take steps to request the party move to an "explicit, informed" consent model prior to honoring the DNT headers coming from the implementation of their tool.

Nick went back and dug up the history on this issue.  It was merged with ISSUE-194<http://www.w3.org/2011/tracking-protection/track/issues/194> in mid-April 2013, and Matthias collected proposals (examples here<http://lists.w3.org/Archives/Public/public-tracking/2013May/0027.html> and here<http://lists.w3.org/Archives/Public/public-tracking/2013May/0016.html>) to be discussed at the Sunnyvale face-to-face meeting in May.

At the Sunnyvale meeting<http://www.w3.org/2013/05/07-dnt-minutes>  the group decided not to pursue this approach.  There was general agreement that adding extra bytes to the signal wouldn't solve the problem, and so we decided (after polling the room) against changing the signal.  This decision was confirmed on the subsequent May 22nd conference call<http://www.w3.org/2013/05/22-dnt-minutes>.  Instead, the group agreed to focus on other ways to ensure that servers don't send DNT signals without the (educated) consent of the user.

At this point, we don't have new information to justify reopening this ISSUE and discussion before proceeding to Last Call.  However, implementation experience may augur for revisiting this (or a related) idea in the future, as the working group was agreed that the potential for the proliferation of signals not reflecting user intent was a considerable concern that we should work to address.