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

On Jan 16, 2012, at 9:27 PM, Jonathan Mayer wrote:
> 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.

Progress involves text in the document that does not have strong objections.
Many people objected to the proposals on first party vs third party.  AFAIK,
we haven't resolved any of those objections.  Quite frankly, the only reason
that you think we are making progress on those issues is because you didn't
seriously address the objections that were made; instead, you argued
unsuccessfully that their concerns didn't matter.  That's okay.  It isn't
your responsibility to resolve those objections. It is the WG's responsibility.

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

For as long as the WG keeps them as separate deliverables, yes.  I personally
think having two documents is a mistake, but it was a mistake made by the
chartering of the group and we aren't close enough to agreement on anything
to reopen that can of worms.

...

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

I would hope not -- it hasn't even reached WG consensus yet.  But I would
like to think that they are looking at it and intending to post any errors
or objections.  It would help immensely if they could write an implementation
report and send it to the WG.

>> 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 text was added in response to a discussion on the WG mailing list
and represented consensus AFAICT at that time (i.e., the bare word
tracking did not have the meaning we were ascribing to it before).
The editor cannot wait for the WG to officially declare consensus on
every issue before text is proposed, since actual text is essential
to the consensus building process.  I tried to get that started,
though, by deliberately bringing that issue to the mailing list for
discussion.

Regardless, adding proposals within the early stages of the document
is part of the role of a W3C editor, and is essential to a fast-track
process like the one we are on.  Getting to FPWD in two months would have
been impossible without it.

We need consensus (or at least reasonable consensus with minority dissent)
on all of the wording before the document can go to last call.  You will
get a chance to advocate removal of anything that you object to when a
call for consensus is made or the corresponding issue is resolved, but
I strongly suggest you find replacement text first that is at least
tolerable to the W3C members that are being called upon to implement
this as a recommendation.

>>>> 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").

See, that's just paranoia talking -- pure politics by advocates who
forget that someone has to actually implement this stuff on *both* sides
of the connection.

I suggest you look into the W3C process.

  http://www.w3.org/2003/06/Process-20030618/policies.html#Consensus

  http://www.w3.org/2003/06/Process-20030618/policies.html#Votes

> 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?

I am deeply troubled by your unwillingness to listen to substantial dissent.
TPE is a work in progress.  The editor's version is even more so.  Please
stop the hyperbole and listen to what people are actually objecting to with
regards to Do Not Track.

Moreover, the editor is appointed by the chairs and can be removed at any
time.  I would hope that they waited until I did something that was actually
contrary to WG consensus, not just something you happen to think lacks
consensus.  We haven't even asked for consensus yet.

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

Like I said, you haven't been listening to the rest of the WG.  Putting
a lid on dissent is not a good idea.

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

When that potential consensus becomes actual text in the TCS document,
then I'll have something to explicitly link to.  Until then, try to read it
as two natural terms, think about why that doesn't satisfy some problem or
use case that you think it should, and attach what you find to the discussion
on the issue that Rigo/Aleecia just opened.  That would be a far more
effective use of your time than arguing that the editor doesn't have a
right to put text in the editor's draft.

....Roy

Received on Tuesday, 17 January 2012 09:11:23 UTC