RE: "cross-site"

Karl,

I believe you're looking at an automated, browser level block whereas I see this more as a 1st party obligation to manage independent of the browser.  If the 1st party receives the DNT signal from the user without a site-specific exception, they would - for that user - not share user specific information with 3rd parties.  Until at such time the user grants an exception or removes their DNT signal.  This would occur "outside" of browser controls.

Assumptions - Each party knows their position in any given circumstance

1. User agent (client, a piece of software) send an HTTP request for 
   http://www.example.org/foo (1st party) with the HTTP header "DNT:1"

2. the server at www.example.org sends a representation (document) 
   for http://www.example.org/foo and log the request tied to the unique ID of that request

3. www.example.org typically passes information about a user to their partner "stats.com" in each beacon fire but now on subsequent fires of the "stats.com" beacon, www.example.org will not pass this information due to the receipt of the DNT signal

4. Additionally, stats.com should obey the user's DNT signal as a self-recognized 3rd party on example.com.  So even in the case where example.com has accidently attempted to pass this information, stats.com should ignore it (unless they are operating as an agent to example.com and therefore know they are able to gather and use this information only for the benefit of example.com and no other customer).

- Shane

-----Original Message-----
From: Karl Dubost [mailto:karld@opera.com] 
Sent: Thursday, November 17, 2011 8:11 AM
To: Shane Wiley
Cc: <public-tracking@w3.org> (public-tracking@w3.org)
Subject: Re: "cross-site"


Le 17 nov. 2011 à 10:22, Shane Wiley a écrit :
> This statement is an attempt to remove the concern that a 1st party, which will mostly likely not be subject to the DNT signal, does not have a backdoor opportunity to pass user data directly to a 3rd party (aka - closing a loop-hole).  3rd parties present on the 1st party's web site should honor the DNT signal directly.

hmmm. but from an HTTP request point of view everyone is 
a first party except if the client sends an HTTP referer [1], [2] 
(which is not mandatory) and can be often ignored.

/me is really trying hard to understand how it is supposed to work 
and be implementable.


So I restart:

1. User agent (client, a piece of software) send an HTTP request for 
   http://www.example.org/foo (1st party) with the HTTP header "DNT:1"

2. the server at www.example.org sends a representation (document) 
   for http://www.example.org/foo and log the request

3. the user agent parses the document and sees there are other links.
   for example a link to http://stats.example.com/blah

4. the user agent sends an HTTP request for http://stats.example.com/blah
   with the HTTP header "DNT:1"

5. the server at stats.example.com sends a representation (document) 
   for http://stats.example.com/blah and log the request


There is *no way* for stats.example.com to know that the HTTP request 
is made because of the initial request on http://www.example.org/foo
EXCEPT if the client sends a "Referer:" HTTP header.
(these are quite broken and used for spams heavily)

The way http://stats.example.com/blah might know about it is because of

* sessionId in URIs - evil, bad architectural design
* cookies or other local storage mechanisms
* tainted uris with parameters and or hash signs
* Browser fingerprinting


[1]: http://en.wikipedia.org/wiki/Referer
[2]: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-17#section-9.7



-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software

Received on Friday, 18 November 2011 02:36:14 UTC