Re: Exception API choices, another variant...

On Jul 24, 2012, at 5:44 PM, David Singer wrote:

> 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.

I think the "fragility" of managing exceptions on the user agent is a feature rather than a bug. That users can change their minds is a good thing, and (I think Shane and I have both been echoing this repeatedly, but in case it's missed) it's an advantage for usability that users can control all of their exceptions in a single place, delete some, turn them all off temporarily and then back on, etc.

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

I'm hopeful for this approach (and I believe this was how the updated text from Tom in February was intended, even if it wasn't clear enough to the group) as it sounds like the essential concern is that user agents should have the flexibility to optionally broaden an exception request if they think that's simpler for their particular users. User agents have flexibility on implementation, no additional round-trips are necessary, sites and users that care to can take advantage of more granular permissions and sites and users that don't care never have to express or see those details. 

I would also suggest that user agents could optionally use other clues to expand the permissions that they retain based on a request. "You've granted requests for example.com on 4 different sites, it sounds like you trust them, should we also grant them a web-wide exception?" "Also grant this exception on other Example Org web sites." etc.

> 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.

My understanding is that this alternative (which in any case is made possible with out-of-band exceptions) is challenging because it's a real burden for first parties to have to pass additional parameters to all possible third parties. I see Shane has already made this point; this common use case was a key motivation for our drafting user-agent-managed exceptions in the first place. Additionally, with in-band-exceptions, third parties never have to second-guess an expressed DNT header.

Also, to be clear, in this example third-party cookie blocking wouldn't be an issue. If the first party is passing on the permission request via URL parameters or similar, it won't matter if the user visited with Safari and didn't send third party cookies because the permission only needs to be stored by the first party and the third party receives the permission from the first party, not from the user agent.

Thanks,
Nick

Received on Friday, 27 July 2012 03:01:25 UTC