Re: [TPE] Remove or truncate section 7.6 Transfer of an exception to another third party

Hi Roy

my recollection is that this is very old text, and achieved consensus and hence we were instructed to insert it as-is; and it has not been review in the light of more recent developments (it predates even the definition of tracking, let alone the precise rules, as I recall). Some, um, cleanup is probably needed.

Action-203 <http://www.w3.org/2011/tracking-protection/track/actions/203> was the initial action, and Rigo supplied the text <https://lists.w3.org/Archives/Public/public-tracking/2012May/0292.html> on 25 May 2012. Given how long ago it was, I am not surprised it is out-dated text.

The actual header values were inserted mid-2013 in response to the resolution of issue-168, from a final tidy-up by Nick. His email  <https://lists.w3.org/Archives/Public/public-tracking/2013Jun/0021.html> talks about the 3rd party that received DNT:0 doing a redirect to the final ad-server, so then the status values come into play:

> Example:
> UA sends DNT: 0 to a particular third party operating an ad exchange or ad auction; the UA is re-directed to another URL (to which the UA sends DNT: 1), but that third party has determined that it has a transferred exception from the ad exchange and replies with the HTTP response header: "Tk: C;foo". An interested UA can load /.well-known/dnt/foo to load the tracking status resource, which will indicate, among other things, "qualifiers": "t", which the UA can communicate to the user as explaining that the resource believed it had consent to tracking the request because of a transferred exception.
> 




> On Feb 2, 2015, at 17:42 , Roy T. Fielding <fielding@gbiv.com> wrote:
> 
> I stumbled across this while reading the TPE diff on last week's call.
> 
> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#transitive-exceptions
> 
> Section 7.6 contains a rather complicated description of what a second
> third party must do when it receives DNT:0 data received from a first
> third party because the first third party has been granted a
> site-specific UGE via some site's first party, wherein the second
> third party is required somehow to use a TSV of "C" (even though that
> is quite impossible unless the user agent is making a request directly
> to that other third party, which would make them a first third party)
> and also a qualifier of "t".
> 
> This has so many problems that I have difficulty even stating them.
> 
> 1) the UA sent DNT:0, so we have no further requirements ... there
>    is no option in DNT for a user agent to tell a third party that
>    "you can track me but don't share any of that tracking stuff with
>     some other third party”.

Interesting, as there is a restriction on 1st parties from doing that:
"A first party to a given user action must not share data about those network interactions with third parties to that action who are prohibited from collecting data from those network interactions under this recommendation. “

This may be a gap in the specification. A 3rd party gets an exception; is it allowed to pass data to another party that does not have an exception?

> 
> 2) there is no request to the second third party, so they cannot
>    respond with "C" even if they could distinguish this new meaning
>    for DNT:0

I think the case envisaged was where the service provision was done by redirection.

> 
> 3) there is no "t" qualifier defined by TCS.
> 
> 4) this section is all about Compliance, so doesn't belong in TPE.
> 
> I would like to delete 7.6.  Please.  If not, we should at least
> delete its last three paragraphs.
> 
> If deleted, remnants of 7.6 could be moved to TCS, though I personally
> believe that none of it would work.  My guess is that the "G" response
> is a better way to address these issues, in general.

I think G was created for the case that the original 3rd party holds the connection and acts as a proxy, yes.

Yes, I think this is about compliance mostly.


> 
> ....Roy
> 
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Tuesday, 3 February 2015 19:18:39 UTC