RE: 409 status code

The first-party script might not have anything to do with DNT, maybe just
updating analytics data. PUTs without authentication are possible here. They
could be for example privacy enhancing by allowing complex activity
statistics about unique visitors to be aggregated without sending unique
identifiers (and identifying the user). A non PII collecting clickfraud
detection system could also be possible.

 

What do you mean by “third party sites”? Would not an XHR to another origin
from a (perhaps externally hosted) JS library be a third-party request? 

 

I assume UAs will just set DNT in an XHR header as long as the general
preference has been set and a general “exception” for the other origin has
not been registered. If the UA or add-on (or compliance scanner) sees a 409
it might take it as a DNT rejection, warning the user or otherwise
registering it. Why should it be necessary to parse the request?

 

Mike

 

 

 

 

 

From: Roy T. Fielding [mailto:fielding@gbiv.com] 
Sent: 26 March 2014 17:56
To: Mike O'Neill
Cc: public-tracking@w3.org; Adrian Bateman
Subject: Re: 409 status code

 

On Mar 26, 2014, at 10:16 AM, Mike O'Neill wrote:





Thought of an interoperability problem with the 409. If script on a page
(accessed with DNT set) does a PUT update against an Azure storage blob
(assuming it supports CORS), a 409 SC might be taken by the UA or add-on as
a third-party rejection of DNT.

 

By interop problem, I meant something that you actually encounter in

practice.  PUT services typically require user authentication and always

retain the data collected (by definition).  Hence, DNT is not a relevant

concern.  If the script is doing this for the sake of tracking, then

it already has access to the window.doNotTrack value and can change

its behavior before the PUT request is sent.

 

Also, CORS-enabled scripts cannot be on third party sites.

That has the same effect as hosting your site on that third party,

which means the first party has no control over data collected and

no ability to adhere to DNT.  It introduces far more security and

privacy concerns than we have addressed with DNT.  I think you should

bring this up when we return to compliance.

 

Regardless, what matters for status codes is: how would receiving a

different status code change the behavior of the user agent?

In both cases, resolving the conflict is not something the UA can

do on its own -- it has to present the message body to the user

so that the user can resolve it.  That is why we don't need a new

status code.

 

....Roy