- From: David Wainberg <dwainberg@appnexus.com>
- Date: Mon, 10 Mar 2014 12:06:53 -0400
- To: "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>, <public-tracking@w3.org>
- Message-ID: <531DE31D.3080002@appnexus.com>
Matthias, On 2014-03-08 6:14 AM, Matthias Schunter (Intel Corporation) wrote: > 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 Roy himself has confirmed the change was substantive and not 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. Who agreed that? I didn't, and as far as I know Jack didn't. -David > > 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 Monday, 10 March 2014 16:07:22 UTC