Re: on negotiating site exceptions

> I agree that this depends on UAs being willing to implement this JavaScript API, manage the client-side state and potentially create new UI.

Nick-- Maybe this is too simple a question, but if browsers do not do it, can third parties (like a browser plug-in) do it?  Can they access the API stream to provide a one-stop shop for managing site specific and web wide exceptions (and out-of band ones as well, though not from the API).

David-- I'd also be interested to know how Safari sees this.

On Apr 9, 2012, at 1:57 PM, Nicholas Doty wrote:

> On Apr 6, 2012, at 12:57 PM, David Singer wrote:
> 
>> 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?
> 
> I think Route A (user-agent-managed site-specific exceptions) is good for the user because the user can go to a single place to clear or modify their exceptions, rather than going back to each site and re-configuring their preferences (which the server then stores in a cookie or via some other mechanism and then overrides the user's DNT preference). As you point out in your example, sites should still be encouraged to use a separate page or innovative UI to explain to the user before using the JS API to make a request (as they would before setting a preference via cookie or other mechanism). It also helps that the user agent has fewer cases where they need to inform the user that a DNT preference is being overridden (potentially by an out-of-band consent that the user remembers) and it means the third-party advertiser never has to second-guess the DNT signal that they receive.
> 
> I agree that this depends on UAs being willing to implement this JavaScript API, manage the client-side state and potentially create new UI. That Microsoft and Mozilla were both actively involved in writing up this section of the spec has encouraged me to believe that browser developers are willing to do so, but if you have particular objections from the Safari team, that would be useful for us to know.
> 
> I also agree that we'll likely need Route B -- there are going to be some cases, for legacy reasons if for no other -- to use out-of-band consent to override a DNT preference, and that that override will be managed on the server side. If we can decrease the number of those cases, I think it will be easier on the whole for users to manage.
> 
> Thanks
> Nick

Lauren Gelman
BlurryEdge Strategies
415-627-8512
gelman@blurryedge.com
http://blurryedge.com

Received on Monday, 9 April 2012 23:18:58 UTC