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

On Oct 31, 2011, at 11:59 , Roy T. Fielding wrote:

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

I completely agree we cannot protect against sites that are both deliberately malicious and deliberately misleading.  However, in working with byte-range headers I have come across a significant number of intermediaries that delete or mangle headers that they don't handle -- including byte-range.  These systems exist, the user typically cannot easily determine they are in path, and if they are, the user[-agent] will not know anything is going on.

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

I am certainly open to other mechanisms.

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

We're into the realms of opinion here, but mine is that it's easy to imagine a browser that keeps a cache of respecting/not-respecting sites.

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

OK, so I probe example-ads.com for /privacy-state.htm, with DNT:1 and it says "sure, I respect DNT in general".  Then I go ahead and visit example-news.com, and example-news tells example-ads that I have explicitly told example-news that its third-party sites may track me.  Under these circumstances I would want example-ads to say "I see your DNT but I am told that you have explicitly consented to tracking on the 1st party site", and that would allow the user-agent to check with the user "is it true that you're OK with the tracking on example-news?"

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


Not sure I follow you…

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Monday, 31 October 2011 19:19:04 UTC