RE: ISSUE-111 - Exceptions are broken

I agree with most of Jonathan's points (thank you for separating these out!) but would like to unravel the several details that I believe are captured a bit outside of the true operating ad serving environment:

#1 - I believe we've covered on the technical reality of this point (accurate DNT status communication to 3rd parties)  Hopefully this dimension is now closed (web-wide exceptions don't carry the pairing complexity as only the serving domain would be captured with the exception).

#2 - The first party knows through polling the site-specific exception list who is covered but won't know this prior to page serving unless we allow server-side polling of the site-specific exception list (something I've raised in other chains - and strongly disagree with Fingerprinting concerns - and would ask we stop harming good actors in attempts to thwart bad actors that have numerous other ways to digitally fingerprint user devices).  If this was possible, publishers could share with an exchange the list of 3rd parties that have exceptions with their property for optimization AND I believe receiving exceptions could become a competitive tool for 3rd parties.  Competition in this manner will ultimately benefit users as 3rd parties would need to impress both the 1st parties they work with and users that an exception is appropriate.  As others pointed out, if publishers and exchanges begin to see specific 3rd parties are not receiving exceptions they will be pressured to rectify their practices to address whatever the concern is with users (self-correcting system).

#3 - 3rd parties often know the 1st parties domain even in multi-step ad serving scenarios and even when dealing with nested iFrames.  There are other initiative underway at the IAB to standardize a safer framing scheme for ad serving to increase security, privacy, and accuracy.  I believe this will further remove this issue as an alternative to direct cross-domain communication models.

#4 - I believe this is even simpler than outlined below.  As a 3rd party if I receive DNT:1, the data is siloed (unless I'm acting as a Service Provider).  As a 3rd party if I receive DNT:0, the data does not need to be siloed.  Where is the complexity here?  If domains in an ad exchange are not directly receiving this signal, it will be fairly straight forward to add this as a signal is the exchange real-time bidding process (Jeff Chester and I discussed this on the mailing list last year).

The main disagreement I have with Jonathan is that the CPM delta is not that great between OBA and other forms of targeting (demo, geo, contextual).  While I know you question the results of the research in this area it is unquestionably true.  As a public company I'm not able to share financial details publically with this group but Yahoo! did contribute data to the research project and the results (OBA = 2.5X to 3X CPM premium over other forms of targeting) is accurate.

- Shane

From: Jonathan Mayer [mailto:jmayer@stanford.edu]
Sent: Thursday, March 08, 2012 9:23 PM
To: Kevin Smith
Cc: Nicholas Doty; VINCENT (VINCENT) TOUBIANA; Sid Stamm; Tracking Protection Working Group WG
Subject: Re: ISSUE-111 - Exceptions are broken

I think there are now at least four different issues that have been raised on this thread.  Let me try to pull them apart.

1) When there are multiple layers of embedding and redirection, how can the browser accurately tell a third party its site-specific exception status?

Browsers already know the top window's domain (top.location.hostname) associated with an HTTP request or resource load.  They have to - otherwise third-party cookie blocking wouldn't work.  I see no problem here.

2) When there are multiple layers of embedding and redirection, how will a first party or third party know the status of a specific third party's site-specific exception?

A third party could easily build a means of sharing its exception status with any of the myriad mechanisms for cross-domain messaging.  We could also provide an explicit API.  (The last proposal of this sort was removed from the TPE draft owing to fingerprinting concerns.)  Again, I see no problem here.

3) When there are multiple layers of embedding and redirection, how will a third party know the first party's domain?

The same way a nested third party currently learns a top-level URL - by cross-domain messaging (most frequently in a request parameter).  A first party could also provide a postMessage-based mechanism for querying its location.  We could develop a new access control API for explicitly allowing reads of top.location.  (I don't think we should - that's unnecessary complexity.)  Yet again, I see no problem here.

4) How can third parties silo data based on exception status?

The same-origin policy makes it easy to silo data that's stored in the browser.  If there's a site-specific exception, you could use a site-specific domain (e.g. cnn.com.doubleclick.net<http://cnn.com.doubleclick.net>).  If there's a web-wide exception, you could use a web-wide domain (e.g. tracking-allowed.doubleclick.net<http://tracking-allowed.doubleclick.net>).  If there's no exception, use a no-tracking domain (e.g. tracking-disallowed.doubleclick.net<http://tracking-disallowed.doubleclick.net>).  If there's data that isn't pseudonymously linkable (e.g. a language cookie), that could get sent to all domains (e.g. .doubleclick.net).  I flatly reject Sean's view that letting the browser handle siloing would result in "truly crazy behavior that is non-implementable for servers."  Again, I see no problem here.

I also want to make a quick response to Kevin's point on monetization.

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

This is a common misconception I've heard about the online advertising market and how it would be affected by DNT.

If a user has DNT enabled, an ad need not be (and most often won't be) random.  I believe there is a consensus in the group that contextual targeting, demographic targeting, and geographic targeting (possibly with some degree of coarseness) would all be allowed.

As for economic impact, it is far from clear that behavioral targeting brings in substantial marginal revenue for publishers.  See http://cyberlaw.stanford.edu/node/6592 and http://donottrack.us/bib/#sec_economics.

On Mar 8, 2012, at 5:18 PM, Kevin Smith wrote:


Excellent point Nick.  I think you're right.  The browser will have to know because no matter how many redirects it goes through, eventually it has to put the content in the right place in a DOM somewhere (I was thinking of what would be available to each stop in the chain rather than what the browser would know when it made the request to each stop in the chain).  So with an '*' for the 1st party site, the browser should be able to send the correct header to each stop in the chain.  Partial crisis averted.

However, I don't believe advertising chains could ever function in a scenario where each 3rd party could be approved individually by the user.  Since the chain is so dynamic, and the 1st party (or even most elements in the chain) do not know what services will be used by the time you get to the end of the chain, exceptions for these items could never by requested.

-----Original Message-----
From: Nicholas Doty [mailto:npdoty@w3.org]
Sent: Thursday, March 08, 2012 4:54 PM
To: Kevin Smith
Cc: VINCENT (VINCENT) TOUBIANA; Sid Stamm; Tracking Protection Working Group WG
Subject: Re: ISSUE-111 - Exceptions are broken

On Mar 8, 2012, at 2:17 PM, Kevin Smith wrote:


As I understand it, an exception for "*" on a first-party site would imply that the user agent would send DNT:0 to every domain from which a resource was requested as part of loading the first-party page (including subsequent re-directs, iframes and XHR requests).

I am not sure how to do this using current methodologies.  Take a simple example.  Site A has an exception for all 3rd parties and includes 3rd Party B which then includes 3rd Party C.  3rd Party C is requested from 3rd Party B, not Site A.  How does the browser know that 3rd Party C's request originated from Site A?  Certainly 3rd Part C probably knows from customized request parameters, but how does the browser map the request to its list of exceptions to even see the '*' associated with site A?  I think this would be new functionality.

We opened ISSUE-110 I believe specifically for this question (will user agents always be able to determine corresponding top-level-origin for all outgoing requests?) as Vincent was concerned that browsers or browser extensions might not be able to do this. I believe Sid informed us that browsers always could (whether it's a redirect, embedded iframe, XHR request, etc.) which is why it was closed -- Sid, can you confirm?

It would seem to me that browsers could always determine what site (or browser tab, say) has initiated a request: when I close a browser window, the browser knows which requests to stop making. When the browser receives a response to an HTTP request, it knows which DOM gets the corresponding JavaScript events or which frame to load the parsed page into.

Thanks,
Nick