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: David Wainberg <dwainberg@appnexus.com>
Date: Fri, 7 Mar 2014 18:11:31 -0500
Message-ID: <531A5223.8020602@appnexus.com>
To: "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>, <public-tracking@w3.org>
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

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