action-241: Propose changes regarding issue-116 (and also "general preference?")

A little background: in response to issue-116 and issue-84 (providing a useful and non-confusing JavaScript property `doNotTrack`), I proposed [0] setting the property to be the value of the header sent to the page, with guidance on how JavaScript should interpret it. Hearing no objections (but with some modifications), I proposed specific text [1] and added it to the spec [2]. Roy had a different interpretation, and changed the draft so that the value of the property would be the general preference rather than the value sent for the particular page [3]. On the August 15th call we discussed whether it should be a general preference rather than the specific value and whether the property should be on window or on navigator and I volunteered to write up what it would be to have a value specific to the site, hung off of window [4].

Phew, so, the relevant changes would be:
Modify 4.3 to add the `doNotTrack` attribute to the Window interface rather than the Navigator interface. (In some sense it could also be on the Document, where we have cookies and referrer, but I believe the most common convention is on Window.)

Note that the value is the value of the header sent to the corresponding origin, not a generalized preference:
> When a tracking preference is <a>enabled</a>, the doNotTrack attribute MUST have a string value that is the same as the <a>DNT-field-value</a> defined in <a href="#dnt-header-field" class="sectionRef"></a> sent in requesting the corresponding document. If a tracking preference is <a>not enabled</a>, the value is <code>null</code>.

I think we would also want to add back in the language I proposed for when scripts should rely on the signal:
> The value of the <code>doNotTrack</code> attribute SHOULD be considered guidance and MUST NOT be interpreted as a guarantee of the value of the DNT header sent on future requests. A user's tracking preference may change and may differ for different origins. Servers MUST rely on the DNT header received in a request even if it differs from what a script previously observed in the <code>doNotTrack</code> attribute. Trackers that commonly expect to receive a user-granted exception (as described in <a href="#exceptions" class="sectionRef"></a>) SHOULD assess the user's preference in the HTTP request loading that script or with the methods defined in <a href="#exceptions" class="sectionRef"></a>.

As Adrian noted on the August 15th call, this would add another variable to the window namespace which could conflict with site-specific code, but I'm not sure how common or serious a problem that would be. This would, however, address Ian's concern about leaking the value of the header to other scripts/windows; as I understand it, the security model would prevent scripts with different effective script origins from accessing properties on the corresponding window object. Furthermore, third-party scripts running within iframes would actually see the DNT header value sent to the origin of that iframe, so that in cases where there was a user-granted exception, the script would see the appropriate "0" value.

With this version of the functionality, we aren't relying on the concept of a "general preference" sent for all requests, which I think would better capture our understanding (user exceptions, browser modes, user configuration, what have you). We might then change section 4.2 to note that the header is sent whenever the user has configured it, rather than on every HTTP request, and use that section to highlight that the value may change between requests. That diff would look like this:

345c345
<           requests if (and only if) a tracking preference is
---
>           requests for which a tracking preference is
378a379,384
>           A user's tracking preference is valid for the context of the HTTP
>           request. User preferences may change between origins and requests.
>           The DNT header value MUST NOT be interpreted as a guarantee of the
>           value of the DNT header sent on future requests.

Thanks,
Nick

[0] http://lists.w3.org/Archives/Public/public-tracking/2012May/0313.html
[1] http://lists.w3.org/Archives/Public/public-tracking/2012Jul/0105.html
[2] http://lists.w3.org/Archives/Public/public-tracking-commit/2012Aug/0025.html
[3] http://lists.w3.org/Archives/Public/public-tracking-commit/2012Aug/0028.html
[4] http://www.w3.org/2012/08/15-dnt-minutes.html

Received on Monday, 10 September 2012 06:31:31 UTC