W3C home > Mailing lists > Public > public-tracking@w3.org > July 2012

RE: Exception API choices, another variant...

From: TOUBIANA, VINCENT (VINCENT) <Vincent.Toubiana@alcatel-lucent.com>
Date: Wed, 25 Jul 2012 11:23:01 +0200
To: David Singer <singer@apple.com>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Message-ID: <4D30AC7C2C82C64580A0E798A171B4445338111939@FRMRSSXCHMBSD1.dc-m.alcatel-lucent.com>

David,

I believe we decided to rely on the UA rather than the first party to transmit the exception because if the UA is not reliable it can block the requests to third parties (e.g. with an ad-blocker). I personally believe that only few users would use such tools with DNT enabled, so I think it would make sense to enforce the exception sent to the third party anyway. 

But if we make that assumption, why don't we just assume that the third party can check the referrer to verify that it has been granted a site exception? That's what I detailed there http://lists.w3.org/Archives/Public/public-tracking/2012May/0117.html (and in following emails). This solution alleviates the dynamic links issue and allows the UA to know which third party are granted an exception (as far as I understand, solution C does not offer this option).

Best regards,

Vincent

-----Message d'origine-----
De : David Singer [mailto:singer@apple.com] 
Envoyé : mercredi 25 juillet 2012 02:44
À : public-tracking@w3.org (public-tracking@w3.org)
Objet : 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 09:24:36 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:44:53 UTC