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 Monday, 10 September 2012 08:08:25 UTC