- From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
- Date: Sat, 08 Mar 2014 12:14:34 +0100
- To: public-tracking@w3.org
- Message-ID: <531AFB9A.8040106@schunter.org>
Hi David, thanks for pointing this out. Quick clarification: - Roy changed the letter signaling 'this sites does some form of tracking' from "1" to "T", which is clearly editorial - Jack asked for an introduction of a new letter "R" Besides this being a non-editorial change, it seems that we now agree that the flag is redundant and not needed since the presence of a compliance URL implies this flag. I hope this answers your question. Regards, matthias Am 08.03.2014 00:11, schrieb David Wainberg: > 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 Saturday, 8 March 2014 11:15:02 UTC