RE: "cross-site"

Karl,

Yahoo! serves ads both on Yahoo! and off of Yahoo! - and we understand our party position in each context and put different business rules into affect for each situation (including specific business rules for a given 1st party we may be serving ads on).  This can be managed a multitude of ways which I've expressed in a separate email chain on 1st and 3rd party discoverability (or in my position - party "setup").

On the "how" - in the use case we were exploring, example.org dynamically assembles its pages and at that time includes the beacon for stats.com - and typically passes some information about users to stats.com for independent use (I don't believe this happens very often in the real world but our goal here is to close on a suspected loop hole).  If example.org sees the DNT signal from user 1234, for all subsequent pages built for user 1234 they would no longer include this add'l information in the beacon call.  This happens server-side during page assembly to be sent to the user's web browser (which is what I meant by outside of browser controls).

- Shane

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


Le 17 nov. 2011 à 21:34, Shane Wiley a écrit :
> 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.

That doesn't work like this. When you have "third parties" on a Web site (banners for example), it is NOT the 1st party which makes the request, but the user. On the Web every entity is a first party. 

>  Until at such time the user grants an exception or removes their DNT signal.  This would occur "outside" of browser controls.

How? 
Outside of browser controls means outside of the Web.


> 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


For this to happen it means, something very simple. It means that the page has to be dynamically generated in a way that do not create any HTTP requests to the 3rd party. 
I'm fine with it, we just created the best AdBlock ever. 

As soon as the user makes an HTTP requests, he/she is tracked. It is not in control of the first party. 

> 4. Additionally, stats.com should obey the user's DNT signal as a self-recognized 3rd party on example.com.  

stats.example.com can know that ONLY with a referer header.
Let me remake the statement very clear:

	The first party DOES NOT control the HTTP requests
	made by the user, once the page has been loaded.


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


How do they know when an HTTP request from an IP address is under the condition of a 1st party or a 3rd party. They don't. Really :) I'm not making that up.



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

Received on Friday, 18 November 2011 02:57:31 UTC