RE: tracking-ISSUE-182 (MikeO): protocol for user agents to indicate whether a request with DNT set is 1st party or 3rd party [Tracking Preference Expression (DNT)]

Mike,

I believe this approach is only helpful for those cases where a 1st party believes its acting as 1st party but is instead "iframed" and acting as a 3rd party without its knowledge.  Telling a 3rd party they are a 3rd party doesn't appear to offer much value.  And in some cases it'll be inaccurate as you're simply telling the Server it's not the top level domain but it may already know that and still be considered first party.  For example, Yahoo! image edge serving domain is yimg.net and when I see that on yahoo.com it's still considered 1st party.

This seems like a tremendous amount of weight to add to the protocol to solve for a rare problem and one that can largely be managed through Server deployment architectures.

- Shane

-----Original Message-----
From: Tracking Protection Working Group Issue Tracker [mailto:sysbot+tracker@w3.org] 
Sent: Saturday, October 20, 2012 7:46 AM
To: public-tracking@w3.org
Subject: tracking-ISSUE-182 (MikeO): protocol for user agents to indicate whether a request with DNT set is 1st party or 3rd party [Tracking Preference Expression (DNT)]

tracking-ISSUE-182 (MikeO): protocol for user agents to indicate whether a request with DNT set is 1st party or 3rd party [Tracking Preference Expression (DNT)]

http://www.w3.org/2011/tracking-protection/track/issues/182


Raised by: Mike O'Neill
On product: Tracking Preference Expression (DNT)

Because request handlers on Servers may in some jurisdictions react differently to 1st party and 3rd party requests, there should be a way for these handlers to transparently differentiate between them. This, together with the returned tracking status response,  will also enable external auditing of logs for DNT compliance. Additionally, in the case of DNT:0 being signalled to reflect the registration of an exception it is also beneficial for the top-level document origin of a 3rd party request to be encoded in the header so that a retained log could be used later as proof of consent, and to aid the debugging of 1st party sites that called the API erroneously.

This is especially important now with the new exception API where the user-agent is not required to confirm agreement with the user.

As an example, here is an edited version of the DNT header ABNF definition that allows user-agents to signal this, and also allows for new extensions to be added as [name,value] pairs. The top level origin is only communicated when the DNT: 0 preference is indicated to inhibit fingerprinting. It could replace paragraph 4.2 in the TPE.

<TEXT>

The DNT header field is hereby defined as the means for expressing a user's tracking preference via HTTP [HTTP11]. 
DNT-field-name         = "DNT"  ; case-insensitive
DNT-field-value        = DNT-preference *(DNT-qualifier *("," DNT-qualifier))
DNT-preference         = "0" / "1"        
DNT-qualifier          = DNT-qualifier-name *("=" DNT-qualifier-value)
DNT-qualifier-name     = first-party-descriptor / third-party-descriptor / DNT-extension-name
DNT-qualifier-value    = top-level-host / DNT-extension-value  
DNT-extension-name     = %x21 / %x23-2B / %x2D-5B / %x5D-7E    ; excludes CTL, SP, DQUOTE, comma, backslash 
DNT-extension-value    = %x21 / %x23-2B / %x2D-5B / %x5D-7E    ; excludes CTL, SP, DQUOTE, comma, backslash 
first-party-descriptor = "f"
third-party-descriptor = "t=" top-level-host

top-level-host  is defined as the host subcomponent (as per RFC3986) of the URI of the top-level page.

A user agent must send the DNT header field on all HTTP requests if (and only if) a tracking preference is enabled. A user agent must not send the DNT header field if a tracking preference is not enabled. 

The DNT-preference sent by a user agent MUST begin with the numeric character "1" (%x31) if a tracking preference is enabled, the preference is for no tracking, and there is not a site-specific exception for the origin server targeted by this request. 

The DNT-preference sent by a user agent MUST begin with the numeric character "0" (%x30) if a tracking preference is enabled and the preference is to allow tracking in general or by specific exception for the origin server targeted by this request. 

The DNT-qualifier third-party-descriptor MUST be present if the DNT-preference is "0" and this HTTP request is for a 3rd party resource, i.e. where the host subcomponent of the request URI is for a different document origin than the top level page.

The DNT-qualifier first-party-descriptor MAY be present if the DNT-preference is "1" and this HTTP request is for a 1st party resource, i.e. where this request is for a top=level page or the host subcomponent of the request URI is for the same document origin as the top level page.

Example ; DNT 1 preference sent to a 3rd party resource

GET /image- HTTP/1.1
Host: imagecloud.com
DNT: 1

Example ; DNT 1 preference sent to a 1st party resource

GET /something/here HTTP/1.1
Host: example.com
DNT: 1f

Example ; DNT 0 preference sent to a 3rd party resource

GET /image HTTP/1.1
Host: imagecloud.com
DNT: 0t=example.com

An HTTP intermediary MUST NOT add, delete, or modify the DNT header field in requests forwarded through that intermediary unless that intermediary has been specifically installed or configured to do so by the user making the requests. For example, an Internet Service Provider must not inject “DNT: 1” on behalf of all of their users who have not expressed a preference. 

The DNT-extension-name rule is reserved for future extensions. User agents that do not implement such extensions must not send them, and Servers that do not implement such extensions should ignore them.

DNT extensions are to be interpreted as modifiers to the main preference expressed by the first digit, such that the main preference will be obeyed if the recipient does not understand the extension. Hence, a DNT-field-value of "1xyz" can be thought of as “do not track, but if you understand the refinements defined by x, y, or z, then adjust my preferences according to those refinements.” DNT extensions can only be transmitted when a tracking preference is enabled. 

The extension syntax is restricted to visible ASCII characters that can be parsed as a single word in HTTP and safely embedded in a JSON string without further encoding (section 5.5.3 Representation). Since the DNT header field is intended to be sent on every request, when enabled, designers of future extensions ought to use as few extension characters as possible.
</TEXT>

Received on Saturday, 20 October 2012 17:19:01 UTC