W3C home > Mailing lists > Public > public-tracking@w3.org > October 2012

ACTION-318 Update draft with JS window/navigator change

From: Nicholas Doty <npdoty@w3.org>
Date: Mon, 22 Oct 2012 20:50:07 -0700
Message-Id: <EAE1FE46-6425-4F40-AD06-1464C86097E6@w3.org>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, David Singer <singer@apple.com>, Adrian Bateman <adrianba@microsoft.com>
To: Tracking Protection Working Group <public-tracking@w3.org>
The diff included below (also attached) would update the draft to move the JS doNotTrack property to window (from navigator) and remove the requestDNTStatus( ) method (which would now be redundant). This builds on my proposal in ACTION-241, with the changes suggested by Roy [0] and with apparent support at the Amsterdam f2f. I remain concerned about possible different interpretations about the granularity of the expressed preference.

Editors, I haven't applied this change yet because I want to double-check that this is what you and the group have in mind.

Thanks,
Nick

[0] http://www.w3.org/mid/87153944-7250-4152-8832-27F86CC191CA@gbiv.com

Index: drafts/tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.171
diff -r1.171 tracking-dnt.html
420,421c420,421
<           A <a>doNotTrack</a> attribute on the <code>Navigator</code>
<           interface [[!NAVIGATOR]] (e.g., the <code>window.navigator</code>
---
>           A <a>doNotTrack</a> attribute on the <code>Window</code>
>           interface [[!WINDOW]] (e.g., the <code>window</code>
423,425c423,425
<           general tracking preference to scripts running within a top-level
<           page. A user agent MUST provide a <code>doNotTrack</code> attribute
<           on the <code>Navigator</code> interface for each top-level page.
---
>           tracking preference to scripts running within a browsing context. A
>           user agent MUST provide a <code>doNotTrack</code> attribute
>           on the <code>Window</code> interface for each page.
427c427
<         <dl class="idl" title='partial interface Navigator {
---
>         <dl class="idl" title='partial interface Window {
436,440c436,439
<             class="sectionRef"></a>) to an origin server that does not have
<             any corresponding user-granted exceptions.
<             When a tracking preference is <a>not enabled</a>, the
<             <code>doNotTrack</code> attribute for each top-level page MUST
<             have a value of <code>null</code>.
---
>             class="sectionRef"></a>) to the origin server for the
>             corresponding window. When a tracking preference is <a>not
>             enabled</a>, the <code>doNotTrack</code> attribute for each page
>             MUST have a value of <code>null</code>.
444,449c443,447
<           The <code>doNotTrack</code> attribute only provides the user's
<           general tracking preference, independent of any user-granted
<           exceptions or out-of-band consent.  A script wishing to determine
<           the specific tracking preference for a given document origin is
<           expected to use the API in <a href="#exceptions-enquiry"
<           class="sectionRef"></a>.
---
>           The <code>doNotTrack</code> attribute provides the user's tracking
>           preference for the window's origin, including any user-granted
>           exceptions. A script wishing to determine the specific tracking
>           preference for a different document origin is expected to use the
>           API in <a href="#exceptions-enquiry" class="sectionRef"></a>.
463a462,473
>         <p class="issue" data-number="160" title="Do we need an exception-query API?">
>             <b>[PENDING REVIEW]</b> It might be useful, and 'complete the
>             model', if we had a JS API that told a host what its current
>             exception status is in a given context. See proposal here.<br />
>             <b>Proposal</b>: The window-level <code>doNotTrack</code>
>             attribute returns the DNT header would be sent to the window's
>             document origin, including whether that origin has a user-granted
>             exception. This obviates the need for a non-parameterized query
>             method. In general the group has not supported a separate
>             parameterized method that would let a script determine the
>             exception status for some other origin.
>         </p>
1709,1731c1719
<       </section>
< 
<       <section id="exceptions-enquiry" >
<         <h2>Querying a host's exception status</h2>
<                 <p class="issue" data-number="160" title="Do we need an exception-query API?"><b>[PENDING REVIEW]</b>
<             It might be useful, and 'complete the model', if we had a JS API that told a host what its current exception status is in a given context. See proposal here.<br />
<             <b>Proposal</b>: Specifically, an API QueryExceptionStatus() which examines the <b>document origin</b> of the script, the current <b>top-level domain</b> and returns an empty string if no DNT header would be sent to that document origin, or the exact DNT header (DNT:1 or DNT:0) that would be sent otherwise.
<           </p>
<           <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
<             <dt>DOMString requestDNTStatus( )</dt>
<             <dd>
<               Returns the same string value that would be sent in a
<             <a>DNT-field-value</a> (<a href="#dnt-header-field"
<             class="sectionRef"></a>) to a <strong>target</strong> that is the
<               document-origin of the request, in the
<               context of the current <strong>top-level domain</strong>. If no DNT
<               header would be sent (e.g. because a tracking preference is 
<               <a>not enabled</a>) the return value is <code>null</code>.
<             </dd>
<           </dl>
< 
<       </section>
<       
---
>       </section>      



Received on Tuesday, 23 October 2012 03:50:17 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:36 UTC