RE: on negotiating site exceptions

Remember, the 1st party does not control the request to the 3rd parties.  That is done by the UA.  So, the only way to pass a flag would be a URL parameter or having the 1st party load all 3rd parties asynchronously (AJAX - which while easy for 1 request, is extremely impractical for all requests).  Plus, whatever URL parameter was attached to the URL would also have to be passed on through the ad chain from 3rd party to 3rd party and would probably not be standardized (I don't recall ever seeing a 'standard' url param).  More than likely, different sites will have different parameter conventions and would require the flag to be passed in under a different name.  So, the point is, although Route B could certainly work, the UA loses both control and the verifiability and we introduce a ton of points of failure since each party would have to participate correctly and not have bugs.  I am not necessarily opposed to this approach, however, if we went down this road I do not see any reason to standardize exceptions at all since a) we will have removed most of the hard work from the UA and placed it back on the sites, and b) I am not wild about having a setting in the browser the outcome of which the browser can neither control nor can verify.

I think if we want to standardize the exception process, route A is the better option.

-----Original Message-----
From: David Singer [mailto:singer@apple.com] 
Sent: Friday, April 06, 2012 10:57 AM
To: public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: on negotiating site exceptions

[I apologize for the slowness of my follow-up here]

I'm trying to work through in my mind how a negotiation between a site that asks for a user to grant an exception, and the user, and their user-agent, might work, and what role the APIs might play in this.  So, I tried this story-board. It forks into two possibilities at one point.

The user sets "do not track" as a general preference.

They visit BogVille Chronicle.

BogVille Chronicle sees their general DNT, and that the user has not paid to see the site; they want to be monetized either by behavioral advertising or by being paid directly.  They re-direct the user to a page that explains "either (a) please create an account and buy a subscription or (b) agree to let my chosen advertisers track you".  They explain all this nicely, in a page, with the advice "choose wisely, earthling!".  The user clicks on the page to say "go ahead, the BVC is totally trustworthy and chooses advertisers of the highest ethical standards and blah blah, go ahead and track me."

This is where I see two possible routes being taken.

ROUTE A

The BVC instructs the UA to remember the confirmation, by executing a script on the confirmation page that tells the user's UA "Heads up, we have a permission grant for BVC advertisers".  The UA confirms this in some way with the user, if it wants, and then remembers in its DNT-database whatever the BVC asked (probably "when on BVC, send DNT:0 to all third parties").

The user returns to the BVC news pages, and the UA sends DNT:0 to the third parties.  (I am not sure what it sends to the BVC first party now, but that's probably not relevant).

ROUTE B

The BVC remembers that this user has given an opt-in; most likely, the confirmation BVC page sets a cookie on the user.

The user returns to the BVC news page, and the BVC sees this cookie, and constructs third-party URLs that include a tag "this user has opted-in to tracking, you (the advertiser) may track them".  The third parties get the request, with a DNT:1 from the UA, and reply saying "we claim an out-of-band opt-in has occurred".  The UA confirms this in some way with the user, if it wants, and also, if it wants, it remembers "don't ask the user again, he's confirmed that the BVC third-parties have an out-of-band opt-in".

* * * * * *

Analysis:

Route B does not need new mechanisms - either JS APIs or an explicit database for remembering which sites to send DNT:0 to.  In fact, we might not need DNT:0 at all in this case; the recording of a grant is done always by some state (probably a cookie) between the user and a site (either first party, or advertiser).  Revocation in Route B is also done with the site in question; a truly 'tight' user-agent might offer the user the ability to delete remembered confirmations of grant.

We probably need Route B to work for other reasons, anyway - the general 'site negotiated opt-in'.

But Route B does have a tension: the UA is sending DNT:1 while 'knowing' that a response 'I have an opt-in' is OK.

Route A has new APIs, and in a sense, a new local storage facility ("please remember to send 3rd parties on the BVC the DNT:0 signal") which, at some level of abstraction, is remarkably like a cookie.  But it does not have the tension recorded above.  I worry that UAs may be slow to implement the APIs and concerned about their implied UI.


* * * * * * *

Question: is Route A needed, or -- especially if we need Route B for other reasons -- is Route B enough?



David Singer
Multimedia and Software Standards, Apple Inc.

Received on Friday, 6 April 2012 17:20:21 UTC