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

On Sep 9, 2012, at 11:31 PM, Nicholas Doty wrote:

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

Okay.

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

If that will satisfy the use cases, okay.

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

It is not guidance.  It should simply say that "A DNT header field received in
a request overrides any prior assumptions based on the doNotTrack attribute,
since a user's tracking preference may change." The rest is either
inconsistent or redundant.

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

That sounds good to me.

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

I disagree with that notion in general. My understanding is that the
WG proposed to send DNT:1 to every first party while the setting is
enabled, thereby indicating when the server needs to make a javascript
request for a site-wide exception (or for specific exceptions for the
subrequest domains that it considers necessary for service).

If the UA is allowed to send DNT:0 to the first party while it is
sending DNT:1 to subrequests, or allowed to send DNT:1 to a subrequest
for which an exception call was made and the exception granted,
then the API is useless.

There needs to be some constraint on the user agent to not send
mixed signals that are inconsistent with the API responses, unless
the user has deliberately changed their config during a page load.

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

That's redundant.  Please don't add extra requirements that are already
encompassed in the definition of the header field.  DNT is already
defined to be specific to each interaction.

> 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

Cheers,

....Roy

Received on Tuesday, 11 September 2012 23:38:06 UTC