RE: on negotiating site exceptions

The difficulty with Route B is it relies on cookies, which may be blocked or deleted. Would an LSO be acceptable for these scenarios? 

What if the user provides an exception using a browser mechanism? I would not expect the browser to place a cookie for a website. I would assume that it would send a DNT:0.

JC
-----Original Message-----
From: David Singer [mailto:singer@apple.com] 
Sent: Friday, April 06, 2012 9: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 19:06:36 UTC