Re: DNT-aware JavaScript (ISSUE-84, ACTION-85)

On Jan 25, 2012, at 4:49 PM, Roy T. Fielding wrote:

> On Jan 25, 2012, at 3:05 PM, Jonathan Mayer wrote:
>> Proposed non-normative text:
>> It is straightforward to make JavaScript aware of DNT status.  In the simplest case, a server can mirror the DNT HTTP header into JavaScript.  For example, in PHP:
>> <?php
>> header("Content-type: text/javascript");
>> if(array_key_exists("HTTP_DNT", $_SERVER))
>> 	echo "var dnt = '';";
>> else
>> 	echo "var dnt = '" . $_SERVER["HTTP_DNT"] . "';";
>> ?>
> Er, please don't do that on a real site -- javascript injection attacks are fun.

header("Content-type: text/javascript");
header("Vary: DNT");
$validDntHeaders = array("0", "1");
$dntHeader = "";
if(array_key_exists("HTTP_DNT", $_SERVER))
	if(in_array($_SERVER["HTTP_DNT"], $validDntHeaders, true))
		$dntHeader = $_SERVER["HTTP_DNT"]
echo "var dnt = '" . $dntHeader . "';";

> In any case, requiring the server to deliver non-cacheable pages is not an option.
> One of the advantages of doing personalization via javascript is that both the
> page and the javascript can be static and extensively cached.  Hence, this
> is not a solution to the issue.

Why not use Vary: DNT?

>> This standard does not include a JavaScript API for DNT status.  A webpage may include scripts from multiple origins; a naive approach (e.g. window.dnt) would give an embedded script the DNT status for the webpage's origin, which may differ from the DNT status for the script's origin.  Providing a DNT status API that accounts for different-origin embedded scripts would introduce implementation challenges for browser developers and script authors and could be a source of fingerprinting information.  Moreover, the first load of a script requires an HTTP request; the server may need to examine the request's DNT header anyways to determine how it may log and use that request.
> I think there is a misunderstanding here.  The only DNT status that this API
> needs to relate is that of the webpage origin.  The DNT status of the script
> origin does not matter

Websites often embed a third-party script that phones home.  We have to support that use case.

> (if it did, then the script origin would be able to
> handle that when the script was requested and deliver a different script).

Yes.  That would be an example of an implementation that is not "the simplest case," and in many cases the better implementation.  But it runs into the same caching issues.

> ....Roy

Received on Wednesday, 25 January 2012 16:17:58 UTC