Re: [ISSUE-81, ACTION-13] Response Header Format

I agree with Matthias's direction on this, and want to add that, in my 
view, dynamic responses to a DNT header do not offer much value for 
compliance enforcement. By far the most, and possibly only, important 
state for compliance enforcement is when user requests DNT, party states 
it intends to honor DNT, and then party tracks anyway. There is no way 
that I know of to reflect this state in any kind of response to a DNT 
header. In my view, making conflicting states transparent to the user, 
e.g. "I will track you although you asked me not to," may be interesting 
to and actionable by the user, but are not very interesting for 
enforcement, because they are transparent. I make this point because, as 
we do the cost-benefit analysis for various response models, we have to 
be clear about which goal we're serving in any particular implementation.

On 10/26/11 7:02 AM, Matthias Schunter wrote:
> Hi David,
>
>
> Thanks for this input. I see these goals once a user has set DNT:
>   - Find out to what extent a request to [someURL] will be tracked
>   - In a machine-readable (=actionable) way
>
> I see two (main) alternatives to implementation:
>   - Response headers with some machine-readable result code
>   - Well-known URL for all sites with a machine-readable
>     representation (this may actually also be a result code).
>
> Since simplicity is one of our goals, I'd prefer the latter if it
> achieves our goals:
>
> Imagine a well-known URL http://[site]/dnt where a file with two lines
> is stored:
>   Tracking: [code] //* similar to the codes discussed for the headers
>   MoreInfo: [URL]  //* Explanations, privacy policy, opt-in, ...
>
> A user-agent can then check [firstparty]/dnt for information and may
> also check [iframes/3rdparty]/dnt for this information. The point is
> that this requires 1 request per site and not 2 lines per http request.
>
> My question is:
>   -  Why (= in what cases) does such a 'site-wide promise to
>      follow DNT' via a well-known location not satisfy your/our needs?
>
> Regards,
>   matthias
>
> The codes may be similar to the codes proposed by you:
>> 100 = I understand DNT and respect it always
>> 102 = I never track anyone anyway
>>
>> 200 = I understand DNT and will not respect it.
>> 201 = I understand DNT but I am exempted as a 1st party
>> 202 = Will not respect because you have explicitly opted in to my tracking
>> 203 = [more exemptions]
>
> On 10/20/2011 12:56 AM, David Singer wrote:
>> I think there are 3 reasons for response headers:
>>
>> * they are temporally proximate; associated with the request and possible tracking, or not, of it;
>> * they are contextual, and allow for precision as to which 'fork' of the policy this transaction is being viewed under (e.g. "you have given me permission")
>> * they are actionable by the user-agent in a way that the privacy policy is not (i.e. the UA can interact with the user and say "this page is loading content from a site that appears not to respond to DNT requests; what would you like to do?")
>>
>> The alternative seems rather unpalatable to all concerned; the UA forms a list of all the 3rd parties involved on a page, and tries to work out, maybe with the user's assistance, using tracking protection lists, and so on, which ones to ignore.
>>
>> I am not a fan of sending of a "please don't track me" into the void and having no idea which sites, if any, are at the moment tracking me.
>>
>> If the policy is static (e.g. sites that do no tracking) it's trivial to add a DNT response to every transaction.  And no, I don't think the extra bytes are very much compared to typical web interactions; "DNT: 200" is vastly shorter than most URLs, for example.
>>
>> I fear that going to the well-known location gets us back into P3P, or worse, only human-readable documents describing what's going on.  (And I use the phrase "human readable" rather loosely for most privacy policy documents :-().
>>
>>
>> On Oct 18, 2011, at 18:25 , Roy T. Fielding wrote:
>>
>>> I think this thread is getting back to the confusion over what we
>>> are trying to control in DNT.  A response of "I will not track you
>>> cross-site" is not something a single resource can decide on its own.
>>> The entire organization has to agree, including the folks who manage
>>> the IP-layer routing, process the web server logfiles, pay the
>>> bounties for referrals, etc.  Compliance is a policy issue for the
>>> entire organization, not just the web application.
>>>
>>> That's why I suggested that a well-known location would be just as
>>> effective, far more expressive, and would remove the issue of caching.
>>> It simply isn't the case that you can visit portions of a site
>>> that says "we won't track you" and other portions of the site that
>>> says "we have an exception for you" and still others that say
>>> "we will track you regardless".  That makes sense for tracking as
>>> a first-party clickstream. It does not make sense for cross-site
>>> tracking, which is either being performed via the use of third-party
>>> mechanisms (i.e., the responses to which will not be made by *this*
>>> site) or by cross-site logfile correlation (something which could
>>> be initiated long after the response was sent).
>>>
>>> If we really need a response header field for the sake of eye candy,
>>> then let's make it specific to resources that perform the actual
>>> cross-site tracking -- the tracking pixels, XHR functions, and
>>> other dynamic devices that might exist in the future for that purpose.
>>> All other resources would have no response header field, and instead
>>> rely on the well-known location for providing the tracking policy
>>> that the entire brand obeys.
>>>
>>> A browser that wants to operate in paranoid mode can retrieve and
>>> cache the well-known location before it makes any other request to
>>> the site, or can selectively retrieve only for those sites that
>>> do not include a response header field, and we don't slow down the
>>> 99% of the Internet browsers that won't have that option selected.
>>>
>>> ....Roy
>>>
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>>
>>
>>
>>
>>

Received on Wednesday, 26 October 2011 21:04:43 UTC