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

I recently joined the group and hopefully coming up to speed on the TPE.
Baycloud Systems is a developer/supplier of website PECR compliance services
and surveys.

Referring to the  comment Rigo made about needing to have higher granular
consent, do that mean exceptions to DNT should be page specific? My reading
of the spec says that the exception API applies to  domain names (not paths
to pages, or have I misunderstood that?). 

If not maybe the language should change to say "fully qualified document
location" rather than domain origin. 

The fully qualified document location is then what 1st origin script gets
from reading document.location (document.location.host would be the domain
origin).
 
The exception registering duplet would then be [document-location, target
domain]

Sites could then give separate exceptions to pages i.e. a commerce page
could allow pay providers to track (if the exception request is honoured so
the http request to those pages would have DNT:0)  but product pages would
not need to, as Rigo said.

Or have I got the wrong end of the stick?

Mike O'Neill
Baycloud Systems.

-----Original Message-----
From: Rigo Wenning [mailto:rigo@w3.org] 
Sent: 10 September 2012 09:08
To: public-tracking@w3.org
Cc: Nicholas Doty
Subject: Re: action-241: Propose changes regarding issue-116 (and also
"general preference")

Thanks Nick, 

I like the proposed changes as I think using cookies for the consent
mechanism doesn't work, especially as users in Europe are known to block
cookies very often. I also think that a consent mechanism needs higher
granularity than just per site or DNS CName. A shopping site can offer an
area where you can look at stuff without being tracked and other areas where
you are tracked. That would be rendered impossible. 

Best, 

Rigo

On Sunday 09 September 2012 23:31:28 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.) 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/2012Au
> g/0025.html [3]
> http://lists.w3.org/Archives/Public/public-tracking-commit/2012Au
> g/0028.html [4] http://www.w3.org/2012/08/15-dnt-minutes.html

Received on Wednesday, 12 September 2012 07:43:30 UTC