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: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
Date: Fri, 07 Mar 2014 08:48:03 +0100
Message-ID: <531979B3.20809@schunter.org>
To: public-tracking@w3.org
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 07:48:30 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:21 UTC