W3C home > Mailing lists > Public > public-tracking@w3.org > March 2014

RE: TPE Editorial Proposal to Remove Another Hard Dependency on the Compliance Specification

From: Shane M Wiley <wileys@yahoo-inc.com>
Date: Fri, 7 Mar 2014 03:32:23 +0000
To: Justin Brookman <jbrookman@cdt.org>
CC: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Message-ID: <DCCF036E573F0142BD90964789F720E3144D3E31@GQ1-MB01-02.y.corp.yahoo.com>
Justin,

I wasn’t suggesting that the signal means something different but rather I believe the current definition of “Tracking” allows some level of refinement in a response to better explain how a company manages its compliance with respect to the signal (as applied to data collected “across multiple distinct contexts”).  I believe I have the answer I need from Roy’s initial response.

Thank you,
Shane

From: Justin Brookman [mailto:jbrookman@cdt.org]
Sent: Thursday, March 06, 2014 9:45 PM
To: Shane M Wiley
Cc: public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: TPE Editorial Proposal to Remove Another Hard Dependency on the Compliance Specification

That's not how I read Roy's comments.

The signal means what it means.  If we define the signal to mean, "hey, don't do X, Y, and Z," you can't respond back "we interpret the signal to mean don't do A."  That's not what the protocol is designed to do.  Instead, you can respond back, "we respond to your request by not doing A," or "we respond to your request by not doing X, Y, and Z," or "we respond to your request by not doing X and Y," or "we respond to you request by not doing V, W, X, Y, & Z."  And then the user or user agent will have to intermediate those responses and decide how to treat the resource accordingly.

In any event, the compliance spec as currently formulated allows for some collection and use of data beyond what the user requests with a DNT:1 signal.  I expect other compliance regimes might do the same thing (though a few implementations today adhere to an absolute Do Not Collect standard that would strictly comply with the DNT:1 request).

But you can't redefine what the header signifies.
Shane M Wiley <wileys@yahoo-inc.com<mailto:wileys@yahoo-inc.com>> , 3/6/2014 9:17 PM:

Roy,



Thank you for the thoughtful response.



Based on your comments below it appears you would feel comfortable if a Server sent back the “T” and a resource link explaining what “Tracking” means to them and how they manage DNT requests?  I believe the core concern is that the TPE hard coded a definition for Tracking where a compliance standard may have a slightly different definition.  I’m looking for a way to bridge the two worlds.



“The existing value of "T" is already sufficient to cover this use case.  It says that the server *might* be tracking as defined by TPE and that compliance (or not) to the user's expressed preference is defined by the combination of the identified compliance regime(s) and the accompanied qualifier values as defined by that regime(s).”



- Shane



From: Roy T. Fielding [mailto:fielding@gbiv.com<mailto:fielding@gbiv.com>]
Sent: Thursday, March 06, 2014 7:50 PM
To: Jack Hobaugh
Cc: Matthias Schunter (Intel Corporation); Justin Brookman; Carl Cargill; public-tracking@w3.org<mailto:public-tracking@w3.org> (public-tracking@w3.org<mailto:public-tracking@w3.org>)
Subject: Re: TPE Editorial Proposal to Remove Another Hard Dependency on the Compliance Specification



On Mar 6, 2014, at 10:06 AM, Jack Hobaugh wrote:



[JLH: Respectfully, I agree that if a compliance regime has a conflicting definition of tracking



That is not a relevant concern.  No compliance spec can redefine what

has already been defined by the protocol.  It can fail to implement the

protocol, but not redefine it.



, it does not change the meaning of the DNT signal or the definition of tracking in the TPE and I agree that the compliance regime will specify how sites respond and also the meaning of those responses.  That is exactly the flexibility that I am requesting through the editorial addition of a TSV “R” value that refers the user to the compliance regime being used by the server.  I am specifically asking for an editorial change to the syntax in adding a TSV value of “R” to the set of current TSV values.  Again, this editorial change does not affect the TPE definition of "tracking" nor does it affect the meaning of the DNT signal.]



What you are requesting is the ability to not respond in a meaningful way

to the user.  The WG has already made clear that a meaningful response is

necessary (in the form of a TSR or header field) in order for the server

to implement the protocol.  Introducing a new response that effectively

says nothing is therefore not an editorial change.



(B) If a site posts a link to a compliance regime at the well-known resource, then this indicates that a site follows this compliance regime and adheres to it.



[JLH: I agree and the “R” TSV value alerts the user to look to that link.  It [R]efers the user to that compliance link.]



The existing value of "T" is already sufficient to cover this use case.

It says that the server *might* be tracking as defined by TPE and

that compliance (or not) to the user's expressed preference is defined

by the combination of the identified compliance regime(s) and the

accompanied qualifier values as defined by that regime(s).



[JLH: The “R” TSV value is only redundant if the server adopts the W3C TCS because the definition of "tracking" will be the same definition in both the TPE and the TCS as the "tracking" definition plus other definitions in the TPE were "ported" from the TCS into the TPE.   But in cases where the server adopts a non-W3C compliance regime, the "R" value is not redundant as it provides a signal to the user to refer to the compliance link for how the server will treat the DNT signal.  This editorial change proposal is within the spirit of Issue-136, removing dependencies on the TCS.  If the server can only respond with a "T," which is tied to a definition from the TCS, then the server is effectively forced to implement at least part of the TCS and again, that may conflict with the non-W3C compliance regime in place on the server.  An "R" value permits the TPE and TCS to be completely uncoupled and provides the possibility for a sever to comply with both the TPE and a non-W3C compliance regime.]



The definition of tracking is in TPE.  Where it came from is irrelevant,

particularly given that the chosen definition was specifically proposed

to be within TPE and never actually appeared in TCS before that.

It was not "ported" from any other document, though that too is irrelevant

to a WG decision. It is part of the protocol.



In short, this is issue-5 and it is closed.  If you don't like it, new

information must be provided (that was not considered in the discussion

leading to the decision on issue-5) if you would like the chairs to

consider reopening it.  Failing that, the choice is to either implement

the protocol as defined or don't claim to be conformant.



Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <http://www.adobe.com/>


Received on Friday, 7 March 2014 03:33:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:40:08 UTC