RE: ACTION-203 : Text for transitive model

Rigo,

We'll have to agree to disagree on this one particular caveat then (UGE trumps DNT:1 for Exchange model) as I believe an exception is a more specific signal (more granular - specific to a particular company) than the broader DNT signal (one time switch affecting everyone).  Since we cannot determine the "freshness" in this case, we should default to the more granular signal, not the broader one.  If a company goes out of its way to obtain a UGE and then cannot leverage this in Exchange situations, it will create disincentives to implement DNT more generally.  We can mark this up as an open issue on the two proposals for the group to decide upon.

- Shane

-----Original Message-----
From: Rigo Wenning [mailto:rigo@w3.org] 
Sent: Monday, June 03, 2013 8:36 AM
To: public-tracking@w3.org
Cc: Shane Wiley; Shane
Subject: Re: ACTION-203 : Text for transitive model

On Monday 27 May 2013 12:59:26 Shane Wiley wrote:
> I believe your text is close and covers many of the open issues we've 
> been trying to resolve.
> 
> One disagreement and one open issue:
> 
>    - Disagreement:  I believe if a Site has received a Site-Wide 
> Exception, this should flow through the auction model as well - FOR 
> THAT TRANSACTION ONLY.  For 3rd party direct exceptions (for example, 
> the ad exchange receives an exception), this is not the case and I
> fully support your text in that case.    

I don't think this is a disagreement. I simply did not have that case on my radar. I do not object to your solution. 
> 
>    - Open Issue:  How does a 3rd party that may have received a UGE
> (DNT:0) from a user in a separate interaction, call upon that UGE in 
> an exchange transaction where they're not able to speak to the UA 
> directly.  For example, Ad Server MNOP receives a web-wide UGE.  An ad 
> placement auction occurs on a site that does not receive a UGE
> (DNT:1) and this is passed into the auction so bidders are aware.  
> When Ad Server MNOP bids on an ad placement on an Exchange, they are 
> able to map to their own cookies and see that this user has granted 
> them a UGE (DNT:0).  Is Ad Server MNOP able to override the auction 
> signal of DNT:1 if they have a record they've received a UGE from the 
> user just prior to that transaction (DNT:0)?  We believe this should 
> be the case.

The legal eagle's solution is to look which of the statements is newer and more specific. As the site permissions are more specific and probably newer, I would think that user expectations are that this is honored. I see you're fighting for a missed opportunity. But I'm of the opinion that this tiny gain is overcompensated by people being frustrated as they expected their special preference (site-specific) to override the general preference (web wide). 

Our case was precisely to get a permission also in regulated environments for those not directly interacting with the user (chain). 
In your case, you can't claim your web-wide exception as you're not interacting with the user, thus you're only deriving permissions from the ones coming down the pipe (auction). And it is simply good engineering and legal construction that a sub-permission can't be greater than the initial permission.

For your edge, this is unfortunate, but it would be the most obvious resolution IMHO. 
> 
> Language slightly updated to cover these two items:
> 
> ---
> 
> A site may request an exception for one or more third party services 
> used in conjunction with its own offer. Those third party services may 
> wish to use other third parties to complete the request in a chain of 
> interactions. The first party will not necessarily know in advance 
> whether a known third party  will use some other third parties.
> 
> If a user-agent sends a tracking exception to a given combination of 
> origin server and a named third party (or the named third party 
> independently), the user agent will send DNT:0 to that named third 
> party. By receiving the DNT:0 header, the named third party acquires 
> the permission to track the user agent and collect the data and 
> process it in any way allowed by the legal system it is operating in.
> 
> Furthermore, the named third party receiving the DNT:0 header acquires 
> at least the right to collect data and process it for the given 
> interaction and any secondary use unless it receives a DNT:1 header 
> from that particular identified user agent.
> 
> The named third party is also allowed to transmit the collected data 
> for uses related to _this_ interaction to its own sub-services and 
> sub-sub-services (transitive permission). The tracking permission 
> request triggered by the origin server is thus granted to the named 
> third party and its sub- services. This is even true for sub-services 
> that would normally receive a DNT:1 web-wide preference from the 
> user-agent if the user agent would interact with this service 
> directly.
> 
> For advertisement networks this typically would mean that the 
> collection and auction system chain can use the data for that 
> interaction and combine it with existing profiles and data.

> The
> sub-services to the named third party also acquire an independent 
> right to process the data for independent secondary uses for that 
> specific transaction if there is a site-wide exception.

Here you blow the limitations that I thought you wanted to have. This would mean that not only the chain could use/track/deliver but all and every third party, which is totally unbound. Is this our intention? I think this is already a consequence of the general principles mentioned above in my response to the issue. It is simply not clean and leads to surprises IMHO. I don't think you need this edge or that it makes much money (for the latter, I'm not really qualified to make an assertion, but still) because the permission is there to deliver the ad. It simply doesn't augment your profile. 


> For 3rd
> party direct exceptions, this is not the case unless they have, 
> themselves, requested and obtained a DNT:0 header from the user agent. 
> In our example of advertisement networks that means the sub-services 
> can use existing profiles in combination with the data received, but 
> they cannot store the received information into a profile until they 
> have received a DNT:0 by their own or the exception in this case is 
> Site-Wide. A named third party  acquiring an exception with this 
> mechanism MUST make sure that sub-services it uses acknowledge this 
> constraint by requiring a "tl" header (5.2.3) from its 
> sub-sub-services.

Received on Monday, 3 June 2013 15:57:13 UTC