Re: Updated Server Response Section of TPE

On Jun 1, 2012, at 9:45 AM, Rigo Wenning wrote:

> Roy, 
> 
> On Tuesday 29 May 2012 18:23:19 Roy T. Fielding wrote:
>>> This means you assume that a browser can send DNT;1 into the wild and
>>> expect  that to work.
>> 
>> No, it doesn't.  It means that the response has no impact whatsoever
>> on whether DNT:1 works or not.
> 
> In this case, the question is: Which semantics prevail, the header or the 
> response? What is binding the server? The status or the header sent?

The header states the user's preference.

If the server conforms to the DNT standard, then it behaves according
to that preference and the sole purposes of the response are to enable
discoverability for preflight avoidance (something only the WKL can
accomplish), to measure deployment (something which is far more
efficient with a required WKL), and to enable dynamic coloring
(or otherwise highlighting) the elements of a page that do not
express support for DNT.

If the server does not conform to the standard, then it is irrelevant
what the server says in response.  We are writing a Recommendation,
not a law.

The protocol exchange is no more binding to the server than it would
be for a person on the street being asked for the current time to be
sure they have an accurate watch.  What binds the server are other
things, like the data protection laws in EU and the false/misleading
statement laws in the US.  Those apply regardless of whether the
statement of DNT compliance is made in protocol messages, resource
representations, privacy policies, or press releases.

> If the status prevails, no need anymore to send a header, right? If the 
> response has no impact on DNT;1, why send it anyway, we could just spare 
> that entire section as it is meaningless according to you. 

Yes, that's what I said in response to the first I-D at the Prague IETF.
There is no need for a response.  There is, however, at least three
expressed desires for a response, and the other fields in the tracking
status representation provide value beyond DNT.  For example, the
control link is specifically to enable compliance with EU laws (and
WH policy initiatives) that demand a mechanism for user control over
the consent mechanism and past data collected.

There is also no need for the request header unless it is known to be
an accurate expression of the user's preference.  If any general-purpose
browser sends it by default, then this entire protocol serves no
useful purpose.  Sending DNT:1 does not improve privacy at all.
The choice by a server to comply with DNT:1 might improve privacy,
but only if there is a reasonable chance that it expresses the user's
choice.  If a server cannot determine that, then it will ignore DNT
or require specific consent from all users, whether or not they
already decided to configure that setting.

If we cannot let each user make that choice on their own, then we
shouldn't have the protocol at all --- we should just have data
protection laws that preserve privacy by default (and are applied
equally to all of industry) instead of inefficient protocol
exchanges of invalid data that are only obeyed by a few good
companies that adhere to Web recommendations as standards.

....Roy

Received on Friday, 1 June 2012 17:56:33 UTC