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

On Oct 31, 2011, at 10:00 AM, David Singer wrote:
> On Oct 30, 2011, at 2:09 , Roy T. Fielding wrote:
> 
>> On Oct 28, 2011, at 7:17 PM, Nicholas Doty wrote:
>>> On Oct 28, 2011, at 1:09 PM, Roy T. Fielding wrote:
>>>> The response is only necessary for the very small percentage of DNT enabled
>>>> browsers, which in turn is just a small percentage of overall browsers, that
>>>> also want to see verification of tracking.  In other words, the ultra-paranoid
>>>> mode or the regulators checking for deployment/compliance.  A user that just
>>>> wants to enable DNT will just send the DNT request header.
>>> 
>>> Do we think only "ultra-paranoid" users will have any interest in the response from the server? One of the goals we identified was to add visibility to the case of opting back in. This seems like a potentially very common situation, given the interest we've heard from advertisers and content providers in having a negotiation with users.
>> 
>> It isn't ultra-paranoid users -- it is a certain mode of browsing where the user
>> wants to be made aware of things like "this image came from a site that might be
>> tracking you".  It is one of those features that sounds okay at first, but ends
>> up being a visual nightmare for anyone other than a privacy researcher.
> 
> I completely disagree.  Sending off DNT into the void, and just hoping, is unacceptable.  Say that by some magic you worked out what third party sites are involved (maybe your browser said "before you visit this site, you should be aware it pulls in 4 new third parties you've not met before"), and that the browser then presents the privacy policies of those sites.  They all promise faithfully to respect DNT, so you go ahead and visit them, sending DNT.  But unknown to you, an intervening proxy is stripping all headers it doesn't recognize, including DNT.  The server is not getting your DNT, your privacy is not respected, and in the absence of a reply, you are none the wiser.
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.

Sending a DNT header field into the void accomplishes all that this standard
needs to accomplish -- it expresses the user's preference such that non-evil
recipients can honor that preference.  There is nothing we can do in the
protocol to prevent intermediaries from being evil, since they can edit the
responses just as easily.  At best, we could reveal accidental loss of
DNT in one direction if and only if that same loss doesn't occur in response.

What I think you are saying is that the solution must be such that a
user wishing to verify receipt of DNT can do so somehow.  IOW, I reject
the notion that this must be accomplished in a response header field,
but if we can accomplish it using some mechanism then it satisfies your issue.

What I am saying is that any form of dynamic verification will be a user
interface nightmare that will not be used by anyone other than privacy
researchers.  That is my opinion from long experience in content management.
Supporting such a feature is a "nice to have".  In other words, the protocol
does not need it, but we should accommodate if possible in any solution
we come up with.  In particular, we should accommodate it in a way that
makes sense for the extremely small percentage of requests being made by
browsers that actively seek verification.

As mentioned before, a single well-known location per site is fully
capable of revealing the accidental loss of DNT described above -- we
just make the response at that location dynamic.  Similarly, if we do
define a response header field, such verification can be accomplished
by limiting the dynamic response to those resources already involved
in dynamic tracking (and hence already non-cacheable).

....Roy

Received on Monday, 31 October 2011 19:02:59 UTC