Re: Status of ISSUE-143

Hi Shane, apologies for the delay, but I wanted to discuss this issue again with the co-chairs before getting back to you (I was not a co-chair last May and was not deeply invested in this particular issue at the time).  The co-chairs and W3C staff don't agree that there was an "explicit agreement" to revisit this topic in the TPE prior to last call after the issue had been addressed in compliance.  Instead, the issue was closed because no one could articulate how revising the syntax of the signal would solve the problem of actors setting the signal in violation of the standard.

To be clear, the issue is not being "side-stepped" because you missed the February 5th call.  On that call, we just explained that we had looked back at the issue's history (after nine months without discussion) and noted that the issue had been closed because of failure to propose a viable technical solution.  A new proposal is not new information and cannot justify the re-opening of closed issues.

Implementation experience may provide new information to justify revisiting this issue, and I invite discussion on the mailing list on this (and any other) proposal to ensure the validity of DNT signals going forward.  However, we are not going to reopen the ISSUE in advance of Last Call.  If you still disagree with this course of action, you can register a Formal Objection with the decision not to reopen the ISSUE.  I believe an email to the public list should be sufficient (as when you and others objected to the co-chairs' decision to reject the tri-part choice requirement: http://lists.w3.org/Archives/Public/public-tracking/2012Oct/0104.html); other guidelines are available here: http://www.w3.org/2005/10/Process-20051014/policies#FormalObjection.

On Feb 21, 2014, at 12:25 PM, Shane M Wiley <wileys@yahoo-inc.com> wrote:

> 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 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 in mid-April 2013, and Matthias collected proposals (examples here and here) to be discussed at the Sunnyvale face-to-face meeting in May.
>  
> At the Sunnyvale meeting  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.  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.
>