W3C home > Mailing lists > Public > public-tracking@w3.org > March 2012

RE: ISSUE-111 - Exceptions are broken

From: Kevin Smith <kevsmith@adobe.com>
Date: Thu, 8 Mar 2012 09:48:08 -0800
To: Rigo Wenning <rigo@w3.org>, "public-tracking@w3.org" <public-tracking@w3.org>
CC: "Roy T. Fielding" <fielding@gbiv.com>, Shane Wiley <wileys@yahoo-inc.com>
Message-ID: <6E120BECD1FFF142BC26B61F4D994CF3064CCAB83C@nambx07.corp.adobe.com>

I think folks in the advertising business could probably answer this a little better as my knowledge on the subject is more academic than from experience.  However, according to my understanding (and I can do some more internal research if we don't have anyone on the thread who can answer this better) - it really depends on each piece of the chain.  I believe each piece of the chain will have its own cookie for the user and will collect the information it needs to be able to fully monetize that individual user, which may be nothing whatsoever (as some parts of the chain are really just pass-throughs), or may be a sophisticated profile which it uses to decide how much to bid for the chance to show an ad to that user.  In general, I do not believe much data flows between the elements of the chain as the data that each piece has collected is essentially their competitive advantage, but I am confident that this is not a hard and fast rule.  Also, since each stop in the chain is trying to maximize their ability to monetize the user, they will each have their own algorithms to determine the next step in the chain.  (For example, once the request gets to ad-service B, according to what it knows about the user, it may send the request to auction service C, or C' etc).  I think in general, most of the information each step uses is information that they have collected themselves, or retrieved from a DMP or similar service.

In your EU example, do services C and D get all the information they need to make a decision from the previous step in the chain, and then discard it after the transaction is complete?  There could be some chains that work this way, but in reality I believe they are vastly more complex than either of us have represented them.  For instance, I do not believe any service which performs real-time-bidding is going to rely on information passed from the ad-service to make its bid.  They are going to have their own way of validating the data.  If they cannot, they are going to bid very low.  This is why the entire chain needs to have the exception for any element of the chain to really work.  If the ad service has the exception, but none of the RTB services do, than they will all bid a minimum bid, which in turn means that the 1st party earns a very low CPM and the exception did not help them at all.

Also, in your example below, since exceptions (at least our site level exceptions) are tied to the 1st party, B would only be able to record your visits to X,Y,and Z if those 1st parties had also been granted exceptions.

Also note, this is just the advertising chain.  I am guessing there may be similar chains for other types of 3rd party services.

-----Original Message-----
From: Rigo Wenning [mailto:rigo@w3.org] 
Sent: Thursday, March 08, 2012 1:47 AM
To: public-tracking@w3.org
Cc: Kevin Smith; Roy T. Fielding; Shane Wiley
Subject: Re: ISSUE-111 - Exceptions are broken


in order for the chain to work, is the full profile of the user exposed to all other parties? 

Imagine I have first party A, ad-service B, auction service C, marketeer D. 
Imagine we have other sites X,Y,Z. So A is my first party and has privileges. 
A uses B for adds. B queries me as a user to get an exception for targeted ads. I grant that to B. Now B records my visits to X,Y,Z. B knows much about me. In order to get the right ad to me, is B no obliged to send my entire profile to C and/or D. Or is it rather that B is saying: "I have a user with categories F, U and D on site X, who wants to send an ad?"

So the exception means that B can collect data. Does it mean that B can spawn to anybody else? In a US context, there are no rules, thus no limitations. So once you've given data to B, the bucket is broken and the water flows out. 
This is an inherent problem of data protection in an unregulated environment. 
So exception as in DNT=0 means that you give data to B and B does whatever. 
DNT can't help with that unless we make a DNT=3 that says: "I collect your data but I will handle it responsibly" meaning giving only aggregated data to third parties. 

In the EU, we are in a regulated environment. There, the exception is scoped by the interaction and its implicit purpose. So by the exception mechanism, B would acquire the right(consent) to establish a profile and keep data. But C and D would acquire information from B for the auction and the serving of an advertisement. Once the auction is done and the advertisement was served, the purpose is exhausted. Further disclosure or processing would need a new permission. But the permission was only given to B and not to C or D. This way, there is no hole in the bucket. (simplified, ask Rob for the nasty

In all cases, the exception mechanism works and brings benefit to consumers and industry alike. So IMHO you just stumbled over the hole in the bucket in unregulated systems.



On Wednesday 07 March 2012 10:02:06 Kevin Smith wrote:
> In planning a response to this thread, I think I may have run into a 
> snag which breaks exceptions completely, both using an * and listing 
> sites individually.  I hope I am overlooking something or that the 
> group has already worked through this and I missed it.
> The fundamental concepts behind DNT are that the user can choose 
> whether or not a site can track them and the site can choose what 
> content to show to a user that it cannot fully monetize.  As far as I 
> can tell, exceptions will not work at all because it does not allow for either of these to happen.
> Consider the following path shown in the attached image where the 
> publisher's ad server redirects to an SSP which redirects to an Ad 
> Exchange which redirects to the Advertiser's Ad Server.  In this case 
> there is a 1st party, and 4 3rd parties (and believe me, this is a 
> fairly simple ad path - the possibilities are nearly limitless).
> The problem is that an exception would apply to the 1st party site and 
> the 3rd party that is included directly on that 1st party site (in 
> this case Publisher's Ad Server).  If the exception does not extend to 
> the remainder of the chain, then the exception is worse than worthless 
> because the 1st party cannot actually monetize the visitor the way it 
> thinks it can.  It will think it can serve a targeted ad, but it will 
> actually serve a house ad or random ad.  It will make its decision on 
> inaccurate information
> * With DNT:0, the ad request moves through the chain shown and returns 
> a targeted ad for which the publisher is paid $x. * With DNT:1, the ad 
> cannot be a targeted ad so the publisher's ad server chooses to go to 
> a completely different ad network and shows a completely random ad for 
> which the publisher is paid $y. * $y is much smaller than $x 
> (obviously the publisher makes more money when it shows a targeted ad 
> than when it shows a random
> ad) * Now, let's assume that this user has granted an exception for 
> the 1st party site and the 3rd party ad server.  The 1st party site 
> receives a
> DNT:0 and the ad server receive a DNT:0 and the site is going to 
> assume it can make $x and will show the content which corresponds to this decision.
> However, once the request hits the 2nd stop in the chain (the ssp in 
> this case), those services receive DNT:1, the process is short 
> circuited, and a random ad, or even a house ad, ends up being shown. * 
> The publisher thought it was making $x, but it made $y and gave its 
> content away for much cheaper than it expected.
> So to recap the problem, using any of the exception models we have 
> discussed so far, there is no way to ask the user whether they are 
> willing to grant an exception to the entire chain (especially since 
> the chain may be completely dynamic and change on a per request 
> basis).  Even with an *, meaning that the exception applies to all 3rd 
> parties on the 1st party site, that exception would still not be 
> applied because the 1st party never makes a request to most services 
> on the chain (the ssp is requested from the ad server, not the 1st 
> party).  So, unless the browser automatically carries on the exception 
> header, I cannot think of any way to get the exception to cover the 
> entire advertising chain which means it will not work.  So, exceptions are broken.  What am I missing?
> -kevin
Received on Thursday, 8 March 2012 17:48:40 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:44:46 UTC