- From: David Wainberg <dwainberg@appnexus.com>
- Date: Fri, 7 Mar 2014 18:11:31 -0500
- To: "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>, <public-tracking@w3.org>
- Message-ID: <531A5223.8020602@appnexus.com>
Matthias, What I don't understand about this is why, if Roy can unilaterally add the T without group discussion or consensus, Jack's proposal is being rejected by the chairs out of hand? -David On 2014-03-07 2:48 AM, Matthias Schunter (Intel Corporation) wrote: > Hi Shane, > > > thanks for your input. It is good that we agree that nobody wants to > redefine the term tracking as it applies to the DNT;1 signal (ISSUE-5). > > IMHO pointing to a compliance regime is possible without any changes. > > 0. A site has published a URL to the compliance regime at the > well-known resource > 1. A user sends "DNT;1" (do not track me according to the TPE definition) > 2. A site responds with "T" (meaning that it cannot fully satisfy this > desire) > potentially adding some qualifiers as defined at the URL > (e.g. "F" for "permitted use 'tracking for fraud prevention'") > 3. The user agent receives and processes the response > > In the compliance regime can then explain the practices of the site in > detail. e.g. > what data is collected, how it is retained and shared, permitted > uses, ... > > I do not see a need for "R" in this scenario. The fact that you > published a URL to a compliance document implicitly says that > this document defines the practices of the site. > > Does this answer your question? > > > Regards, > matthias > > > > > Am 07.03.2014 04:32, schrieb Shane M Wiley: >> >> 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 23:12:00 UTC