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

I have no problem removing that section of text.

More responses inline. tl;dr: we state elsewhere in the spec that parties can claim consent with a "C" response value, which is still what we want. The "t" qualifier is just a suggestion.

Nick


> On Feb 3, 2015, at 11:18 AM, David Singer <singer@apple.com> wrote:
> 
> 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 <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.

For what it's worth, I think this example is still accurate. This isn't the gateway case, but the redirection case, where a provider to which you sent DNT:0 re-directs you (301/302) to another party, and sends a parameter or otherwise indicates to that additional server that they had consent from the user for this exchange. In the text, we suggest that a qualifier of "t" could be used to indicate if a server is claiming transitive consent (you gave permission for a.com <http://a.com/> to track you and they re-directed to us).

I'm not aware of any implementer that wants to use this transitivity as a claim of consent and wants a machine-readable way to indicate that to a user/user agent. We don't formally define "t" as a qualifier in the Compliance document. I suppose we could do so, but it might be the kind of thing we would indicate "as risk" as we're not sure it will be used. (I share some of the skepticism about handling consent that way.)

>> 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. “

That restriction is for first parties to a given user action that receive a DNT:1 signal. (Should I clarify that in the Compliance text? I think it's just assuming the condition in the previous sentence, but maybe that's not sufficient.)

> 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?

This is the current text about DNT:0 in Compliance, which I believe is an accurate representation of our intentions:
>> This recommendation places no restrictions on collection or use of data from network interactions with DNT:0 signals. Note, however, that a party might be limited by its own statements to the user regarding the DNT:0 setting.

If you receive DNT:0, then Compliance puts no restrictions on you. But if you receive DNT:0 from a user because you promised to only share it with certain people, you are of course bound by your own promises to your users.