- From: David Singer <singer@apple.com>
- Date: Mon, 17 Sep 2012 14:13:22 -0700
- To: Rigo Wenning <rigo@w3.org>
- Cc: public-tracking@w3.org, "Roy T. Fielding" <fielding@gbiv.com>, Nicholas Doty <npdoty@w3.org>
On Sep 17, 2012, at 12:57 , Rigo Wenning <rigo@w3.org> wrote: > On Tuesday 11 September 2012 16:37:45 Roy T. Fielding wrote: >> If the UA is allowed to send DNT:0 to the first party while it is >> sending DNT:1 to subrequests, or allowed to send DNT:1 to a >> subrequest for which an exception call was made and the exception >> granted, then the API is useless. > > Wasn't the API defined this way so the first party could know which > of its third party get an exception? Because the first party can't > know if the browser sends DNT:0 to a third party. I dealt with most of this issue by requiring that exceptions are granted in their entirety or not at all. How the first party tracks whether the exception is still 'alive' is tracked as an open issue (111), for which the spec. currently has this discussion: "A previous proposal was that it can add itself to the list (i.e. an exception for [site, site]) and then it will get DNT:0, but DNT:0 to a first party means something different (that it can pass data to third parties, and tracking is permitted). It would be better to have an indication in the DNT header that one or more site-specific exceptions exist for the given target (i.e. that there is at least one duplet in the database with target as its first host name), for example "DNT:1E" where E means you are a first party with one or more active exceptions." Give the 'atomic request' nature of the requests, the first party really now only needs the true/false, I suspect. > > Rigo > David Singer Multimedia and Software Standards, Apple Inc.
Received on Monday, 17 September 2012 21:13:53 UTC