RE: meaning of DNT 1 and DNT 0 when sent by user agents [ISSUE-78]

> I'm not sure what you mean by "not making any progress" on the "actual protocol semantics."  We're moving closer to text on the first party vs. third party distinction, and we're working on enumerating the exceptions for permitted data collection/retention/use.  That sure sounds like progress to me.

Perhaps what he means is that a large contingent of the working group does not think that first vs third party definitions are even relevant.  And until we determine what we are progressing towards which is clearly less clear than many of us thought it was, it is by definition impossible to make progress.

However, in the short term, I think it's best to agree to disagree.  Roy is clearly not going to follow Jonathan's suggestion until/unless he feels the rest of agree with him, which we don't (at least not all of us).  So, I suggest we table this conversation until we have a few more relevant ones in person next week.

-----Original Message-----
From: Jonathan Mayer [mailto:jmayer@stanford.edu] 
Sent: Monday, January 16, 2012 10:27 PM
To: Roy T. Fielding
Cc: public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: meaning of DNT 1 and DNT 0 when sent by user agents [ISSUE-78]


On Jan 16, 2012, at 8:24 PM, Roy T. Fielding wrote:

> On Jan 16, 2012, at 5:44 PM, Jonathan Mayer wrote:
>> On Jan 16, 2012, at 4:46 PM, Roy T. Fielding wrote:
>>> On Jan 16, 2012, at 4:10 PM, Jonathan Mayer wrote:
>>> 
>>>> In responding, I'm going to try to give some shape to the issues in this thread (both explicit and implied).  I believe what I'm saying here is, for the most part, non-controversial.
>>>> 
>>>> 1. Should there be non-protocol content in the TPE document?
>>>> No.  The TPE document specifies a protocol.  The TCS document specifies a policy.  That clear boundary has existed since at least the Princeton workshop, and it has served us well in advancing the protocol despite deep policy differences.  I see no reason to blur the protocol-policy divide now.  Especially not the unsupported concern that developers will have trouble with two documents instead of one.
>>> 
>>> I am not interested in the fantasy of continued "progress" in which 
>>> every participant has a different notion of what we have agreed to 
>>> implement, let alone standardize.
>> 
>> I'm not quite sure what you mean.
> 
> I mean that we have not been making any progress on the definitions 
> because we keep punting the actual protocol semantics down the road.
> 3rd party is FAR less relevant than tracking.

I'm not sure what you mean by "not making any progress" on the "actual protocol semantics."  We're moving closer to text on the first party vs. third party distinction, and we're working on enumerating the exceptions for permitted data collection/retention/use.  That sure sounds like progress to me.

>>> Defining the meaning of a header field is part of the protocol, not 
>>> the policy.
>> 
>> I fear there may be a mismatch in terminology, so let me try to be clearer.  By "protocol," I mean the format for message-passing between a user agent and a server.  By "policy," I mean the limits a particular message imposes on a website's business conduct.
> 
> The former is protocol syntax.  Protocol includes syntax and semantics 
> over the course of multiple interactions.
> 
> What a recipient must do in response to received semantics is also 
> protocol, though in this case it is separated out into a separate 
> compliance document.  Note that the text I used for DNT meaning does 
> not in any way express what the recipient must do in response (Tom's 
> suggested change did, but that's easy to edit).  It only stated the 
> meaning being expressed.

In the interest of avoiding linguistic ambiguities, I'm going to take a step back from the (admittedly fuzzy) protocol vs. policy and syntax vs. semantics distinctions.  I think we are in agreement that, at a high level, the TPE document should not contain operative language about "[w]hat a recipient must do in response to received semantics."

>> Many standards either lack a policy component or include a fairly negligible policy component.  For TPWG, policy is unusually salient.
> 
> No, not really.  It is just the nature of the WG membership that folks 
> are making policy arguments when they should be reaching out for an 
> agreement on what people are willing to implement.

I think you've misunderstood me.  I meant policy in the sense of protocol vs. policy, not a broader claim about member interactions and motivations.

>>> Definition of terms are essential to meaning.
>>> Without them, the HTTP communication is just babble.
>> 
>> Agreed.  That's why the TCS text is quite important.
>> 
>>> Since implementations are already being based on the TPE spec alone,
>> 
>> Some websites change their business practices when they receive the "DNT: 1" header.  (See http://donottrack.us/implementations.)  I would strongly object to the claim that these implementations are "based on the TPE spec alone."
> 
> Up until the FPWD, yes.  Now the same people are looking at TPE instead.
> If you think they are looking at the compliance spec for that info, 
> then you must be thinking of a different spec than the one I can see.

I've worked with several implementers since the FPWD.  None relied on the TPE language extensively, let alone exclusively.

>> Implementers have looked to a wide variety of sources, including this group's drafts, the IETF Internet-Draft, Mozilla's materials, DoNotTrack.Us, and much more.  This isn't a bald assertion on my part - I've been privileged to work with a number of implementers.
>> 
>>> I will include in the TPE spec whatever definitions are necessary to 
>>> understand the WG's intended communication.
>> 
>> I'm no expert in W3C process, but as I understand it (see https://lists.w3.org/Archives/Member/chairs/1999JanMar/0056) the role of an editor is to capture the group's consensus view.  If my reading is correct, then with all due respect - and I do sincerely mean that, I greatly appreciate your efforts in this working group and your extraordinary contributions to the web - you "will include include in the TPE spec whatever" this group tells you to include.
> 
> Yes, once the group has consensus.  So far, your position does not 
> match what content providers are willing to implement, and I am not 
> the only person disagreeing with you, so we don't have consensus.

I recognize that, if there is not consensus on an issue, text may not go into the document.  What we have here is a different case - where there is not consensus on an issue, but text has nevertheless been added to the document.

>>> The fact that those
>>> definitions are supposed to be owned by the Compliance spec is 
>>> irrelevant until last call.
>> 
>> I'm not sure what you mean by "supposed to be owned" and "irrelevant."  If you're claiming that you can arbitrarily pull pieces of the TCS document into the TPE document, I think many in the group would object for myriad reasons.
> 
> I am the editor -- it is my job to throw text at the document that 
> roughly corresponds to what *each* of us want in the spec, until it is 
> ready for a consensus call for *all* of us.  Consensus might take the 
> form of new, modified, or deleted text.  Until then, I can bring in 
> text from any source I happen to think is relevant that has been 
> contributed to the W3C, along with whatever I happen to think up as we 
> go along.  That's how almost all of the text got there.  TCS is the 
> safest source to pull text from (and move text to).
> 
> You can object all you like -- in fact, I encourage it whenever you 
> disagree with the content of the spec -- just don't expect a change in 
> the editor's working draft until consensus is determined.

I'm not at all comfortable with this.  Another member of the group sent me an email in reply to your comments that termed them a "unilateral power grab."  (I'll leave it up to that member to decide whether to provide attribution for the statement, since it's clearly controversial.)  While I wouldn't go so far myself, please understand that you are claiming an extraordinary power of the pen.  In a group so rife with nuanced disagreements, I fear running roughshod over text will only prompt unnecessary, distracting, and time-consuming spats (e.g. "cross-site tracking").

Moreover, I'm deeply troubled by the combination of this asserted authority with your perception that the TPE document has outsized influence.  Taking your views at face value, you believe you have a near-term monopoly on how Do Not Track is implemented.  How could you not see that as problematic?

> What I want is a document that makes sense, is readable, and 
> corresponds exactly to what the WG has agreed as the standard for DNT.

I think all share that view.

> IMO, the way
> to get there is to write down what we've agreed to implement first and 
> worry later about in which document (or both) it belongs.

I could not disagree more.  If procedure is unclear, it will take far longer to attain consensus on substance.  Case in point: the TCS discussion had, at least for a short while, successfully put a lid on the useless "What is tracking?", "What is cross-site tracking?", "What about Do Not Cross-Track?" roundabout.  Because it was not clear that TPE would not address the issue, it's been reopened.

> If we have agreed that DNT impacts cross-site tracking but not all 
> tracking, then that's exactly what I'll write until the WG agrees to 
> something else or defines a better term/phrase to replace it.

I do not believe there is consensus that "DNT impacts cross-site tracking but not all tracking," in the absence of a careful definition of "cross-site tracking."  I believe there may be a consensus in favor of an arbitrary term ("cross-site tracking," "tracking," or something else) in the TPE document that is explicitly linked to the TCS document.

>>> In any case, there is no definition of tracking in the Compliance 
>>> spec right now.
>> 
>> If you could make this explicit in the text, I think it would resolve some ambiguity.
> 
> Yes, I intend to do that soon.  Note that TPE already says:
> 
>   A companion document, Tracking Compliance and Scope, more
>   precisely defines the terminology of tracking preferences,
>   the scope of its applicability, and the requirements on
>   compliant first-party and third-party participants when an
>   indication of tracking preference is received.
> 
> ....Roy
>

Received on Tuesday, 17 January 2012 06:38:29 UTC