RE: Exception API choices, another variant...

David,

I'd rather we not break the existing structure that works for site-wide and web-wide exceptions in the quest to fulfill the explicit-explicit exploration.

"...it's the job of the first party to relay to their chosen third parties the existence of this exception (as a URL parameter, probably)"

This approach will simply NOT work as often the 1st party is not in a position to directly communicate to a 3rd party due to other privacy and security preserving technology approaches (double nested iFrames, intermediated calls, etc.).  The ONLY party in a transaction that has clear line of sight to both the 1st party and 3rd parties on a respective page is the UA and it alone should have the responsibility to communicating DNT:1/0 to all parties on the page (especially since this is where the DNT signal is set!).  The current draft supports this and its only the attempts to cover explicit-explicit that seem to break the "ease" of this model.

- Shane

-----Original Message-----
From: David Singer [mailto:singer@apple.com] 
Sent: Tuesday, July 24, 2012 7:44 PM
To: public-tracking@w3.org (public-tracking@w3.org)
Subject: Exception API choices, another variant...

I was looking at the exception API again, in the light of comments on the last call, and previously from Ian and others, and I want to lay out some choices, because there is one I don't think we have considered.

A] The original API I wrote up has the parameter to the site-specific API, of the list of third-parties that the first party wants/needs to receive dnt:0, not dnt:1.  This suffers from problems as reported by Ian and myself; it's awkward to handle on the UA side, and the server might not like delegating to the UA which sites will get the dnt:0 -- the first party can't tell if the user or UA subsequently silently deletes some of them, for example.  It's fragile.

B] Then there is as I wrote it up for Matthias; the parameter is removed, the UA can fetch the list from the site, or use '*'.  This suffers from the (optional) extra round-trip, and all the same problems as [A], plus the problem that a site that wants exceptions for only some third parties (the trusted, needed ones) can no longer be sure whether the UA will broaden to '*', all third parties.

B.1] We can get rid of the extra round-trip, by making the site-list a parameter, but still making it optional that the UA take any notice of it.  We can let the first party know what happened, in the call-back (the user/UA (i) agreed to your list (ii) broadened it to '*', (iii) rejected the request).  

We still have the issue that the first-party is delegating future behavior (who gets dnt:0) to the UA.  A and B also have the thorny issue of re-directs -- should the dnt header be copied to the target, or should the target have an independent decision made for it?

C] Ian, on the call, mentioned that the UA recording is useful because it may well be that cookies are being blocked.  That made me think.  Perhaps it is better than the response to a site-specific request is a simple 'yes' or 'no (just like web-wide), and then the dnt header sent to FIRST party tells it "you have a site-specific exception", and it's the job of the first party to relay to their chosen third parties the existence of this exception (as a URL parameter, probably).

For me, this is attractive; the first party retains visibility into the existence of the grant, and retains control over the set of third parties it relays the grant to.  We can have a value of the well-known-resource/response header that allows a third-party to say "I have an exception because the first party told me so", and this is check-able by the UA (did I, in fact, tell the first party they have a site-specific exception?).

For the UA, it's now very simple; I record two lists of sites, those that have site-specific exceptions, and those that have web-wide, and when I contact them, I tell them that fact.  The user CAN manage these lists, as they make sense; we don't dazzle them with the names of sites that mean nothing to them.



Why is this different from cookie-based opt-out?  (a) it's using a new mechanism, not cookies.  (b) cookie-based opt-out requires the user contacting the *advertisers* (third parties) albeit moderated by sites such as the IAB, but none of these (including the IAB) are sites the user would usually visit.  This, on the other hand, is handled by the first party, the site the user wants to and has visited.

With design C, I am not sure we need or should have out-of-band exceptions any more.  C leaves in the UA's hands the question "do I let this site have an exception?" and leaves in the sites hands "what is the operational effect of the exception?", which also feels like the right balance, to me.

C has the one down-side that the first party has to pick up the value of the DNT header (or use the equivalent Javascript API), and use it as part of the input in making dynamic URLs for their third parties, but that's how they get the control and visibility over which third parties get the indication.



David Singer
Multimedia and Software Standards, Apple Inc.

Received on Wednesday, 25 July 2012 12:18:55 UTC