W3C home > Mailing lists > Public > public-tracking-commit@w3.org > January 2013

Re: CVS WWW/2011/tracking-protection/drafts

From: David Singer <singer@apple.com>
Date: Tue, 15 Jan 2013 16:35:15 -0800
Message-id: <CCD7D86E-8EF9-4E19-94CC-87D0540C635A@apple.com>
To: public-tracking-commit@w3.org
I've asked Nick to check 4.3

On the confirm calls, I expect even if we add either or both of the "and sub-domains" and/or "and my same-party sites", I would leave the confirm calls as-is, confirming whether "I" have the expected exception.  Complicating them doesn't seem needed.


On Jan 15, 2013, at 16:28 , CVS User dsinger2 <cvsmail@w3.org> wrote:

> Update of /w3ccvs/WWW/2011/tracking-protection/drafts
> In directory gil:/tmp/cvs-serv643
> 
> Modified Files:
> 	tracking-dnt.html 
> Log Message:
> Edits for actions 
> 345 - add section for sites that do not normally have a visual/JS presence (from
> Nick's text)
> 348 - ensure that the API allows the UA to pend the store while getting user
> approval
> 349 - add 'confirm' APIs for both site and web-wide exceptions
> 351 - remove the 'what is the user's general preference' check, and move the
> ';what header would I receive' call to that section in the document (still needs
> Nick to base this call on the right JS object)
> 353 - duplicate of 349
> 
> 
> 
> --- /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html	2012/12/07 00:26:44	1.174
> +++ /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html	2013/01/16 00:28:17	1.175
> @@ -421,55 +421,25 @@
> 
>       <section id='js-dom'>
>         <h3>JavaScript API to Detect Preference</h3>
> -        <p class="issue">This call is a candidate for deletion, relying only on the
> -        origin-specific call below (Nick Doty's suggestion).
> -        </p>
> -
> -        <p>
> -          A <a>doNotTrack</a> attribute on the <code>Navigator</code>
> -          interface [[!NAVIGATOR]] (e.g., the <code>window.navigator</code>
> -          object) is hereby defined as the means for expressing the user's
> -          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.
> -        </p>
> -        <dl class="idl" title='partial interface Navigator {
> -                                 readonly attribute DOMString doNotTrack;
> -                               };'>
> -          <dt>readonly attribute DOMString doNotTrack</dt>
> -          <dd>
> -            When a tracking preference is <a>enabled</a>, the
> -            <code>doNotTrack</code> attribute for each top-level page MUST
> -            have the same string value that would be sent in a
> +                <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 origin</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>
> +          <p>This call enables a site to determine what DNT header would be sent to it
> +          in the current context, taking into account the user's general preference 
> +          (if any) and any exceptions.</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 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>.
> -          </dd>
> -        </dl>
> -        <p>
> -          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>.
> -        </p>
> -        <p>
> -          A user agent MUST provide a <code>doNotTrack</code> attribute
> -          value that is consistent with the user's current tracking
> -          preference that would be expressed via the DNT header field.
> -          However, changes to the user's preference might occur between
> -          the time when the APIs are checked and an actual request is made.
> -          A server MUST treat the user's most recently received preference as
> -          authoritative.
> -        </p>
> -        <p class="issue" data-number="116" title="How can we build a JS DOM property which doesn't allow inline JS to receive mixed signals?">
> -          <strong>[PENDING REVIEW]</strong>
> -          Updated text in this section.
> -        </p>
> +            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 origin</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 id='plug-ins'>
> @@ -1501,7 +1471,7 @@
> 		  User-agents MUST handle each API request as a 'unit', granting
> 		  and maintaining it in its entirety, or not at all. That means
> 		  that a user-agent MUST NOT indicate to a site that a request for
> -		  targets {a, b, c} has been stored, and later remove only one or
> +		  targets {a, b, c} exists in the database, and later remove only one or
> 		  two of {a, b, c} from its logical database of remembered grants.
> 		  This assures sites that the set of sites they need for
> 		  operational integrity is treated as a unit. Each separate call
> @@ -1552,7 +1522,7 @@
>         <h2>JavaScript API for Site-specific Exceptions</h2>
> 
>         <section id="exceptions-javascript-api-rqst">
> -          <h3>API to request site-specific exceptions</h3>
> +          <h3>API to Request a Site-specific Exception</h3>
> 
>           <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
>             <dt>integer storeSiteSpecificTrackingException (
> @@ -1609,11 +1579,12 @@
>           <ul>
>             <li><code>0</code> indicates a syntax or other operational error.</li>
>             <li><code>1</code> indicates that the request was for specific 
> -            <strong>target</strong>s and the the user-agent has stored an exception on
> +            <strong>target</strong>s and the the user-agent has stored or will store 
> +            an exception on
>               <strong>top-level origin</strong> for those specific
>               <strong>target</strong>s.</li>
> -            <li><code>2</code> indicates the user-agent has stored a site-wide exception
> -              on <strong>top-level origin</strong> for all
> +            <li><code>2</code> indicates the user-agent has stored or will store
> +            a site-wide exception on <strong>top-level origin</strong> for all
>               <strong>target</strong>s; the request may have been for
>               specific <strong>target</strong>s or for a site-wide exception.</li>
>           </ul>
> @@ -1627,7 +1598,7 @@
>           </p>
>           <p>
>             If permission is stored for a site-wide exception, then the
> -            duplets:
> +            duplet:
>           </p>
>           <pre>[document-origin, * ]</pre>
>           <p>
> @@ -1641,8 +1612,10 @@
>           <p class="note">
>             The prior version of this call was asynchronous with a call-back; the change
>             to require the site to determine the user's wishes, rather than the UA,
> -            enabled this to become synchronous.  This is simpler, unless the UA
> -            wishes to ask the user and not store until the user agrees.
> +            enabled this to become synchronous.  This is simpler; the user-agent may 
> +            still ask for the user's approval. Sites wishing to know whether an 
> +            exception stands, or the DNT header that they would receive,
> +            should call the appropriate enquiry API.
>           </p>
>         </section>
> 
> @@ -1667,6 +1640,70 @@
>           some kind of processing error occurred.
>           </p>
>         </section>
> +        
> +        <section id="exceptions-javascript-api-confirm">
> +          <h3>API to Confirm a Site-specific Exception</h3>
> +
> +          <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
> +            <dt>boolean confirmSiteSpecificTrackingException (
> +                  optional sequence&lt;DOMString&gt; arrayOfDomainStrings)
> +            </dt>
> +            <dd>
> +              Called by a page to confirm a site-specific tracking
> +              exception.
> +            </dd>
> +          </dl>
> +
> +          <p>
> +            The <code>confirmSiteSpecificTrackingException</code> method takes
> +            one optional argument:
> +          </p>
> +          <ul>
> +            <li><code>arrayOfDomainStrings</code>, a JavaScript array of
> +              strings,</li>
> +          </ul>
> +          <p>
> +            If the call does not include the
> +            <code>arrayOfDomainStrings</code>, then this call is top confirm a
> +            site-wide exception. Otherwise each string in
> +            <code>arrayOfDomainStrings</code> specifies a
> +            <strong>target</strong>.
> +          </p>
> +          <p>
> +            If the list <code>arrayOfDomainStrings</code> is supplied, and the
> +            user-agent stores only site-wide exceptions, then the user-agent
> +            MUST match by confirming a site-wide exception.
> +          </p>
> +          <p>
> +            The execution of this API uses the 'implicit' parameter, 
> +            when the API is called,
> +            the <strong>document origin</strong>. This forms the first part of
> +            the duplet in the logical model.
> +          </p>
> +          <p>
> +            If the user-agent stores explicit lists, and the call includes one, the
> +            database is checked for the existence of all the duplets (one per target):
> +          </p>
> +          <pre>[document-origin, target]</pre>
> +
> +          <p>
> +            If the user-agent stores only site-wide exceptions or the call did
> +            not include an explicit list, the database is checked for the 
> +            single duplet:
> +          </p>
> +          <pre>[document-origin, * ]</pre>
> +
> +          <p>
> +            The returned boolean has the following possible values:
> +          </p>
> +          <ul>
> +            <li><code>true</code> all the duplets exist in the database;</li>
> +            <li><code>false</code> one or more of the duplets does not
> +              exist in the database.</li>
> +          </ul>
> +        </section>
> +
> +
>       </section>
> 
>       <section id="exceptions-ww-javascript-api">
> @@ -1699,16 +1736,16 @@
>           </p>
>           <ul>
>             <li><code>0</code> indicates a syntax or other operational error.</li>
> -            <li><code>1</code> indicates that the request was stored.</li>
> +            <li><code>1</code> indicates that the request was or will be stored.</li>
>           </ul>
> 		  <p class="note">
> 		  	As above, this call used to be asynchronous, and the change to the UI
> -		  	enabled it to be sycnhronous.
> +		  	enabled it to be synchronous.
> 		  </p>
>         </section>
> 
>         <section id="exceptions-javascript-api-ww-cancel">
> -          <h3>API to cancel a web-wide exception</h3>
> +          <h3>API to Cancel a Web-wide Exception</h3>
> 
>           <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
>             <dt>boolean removeWebWideTrackingException( )</dt>
> @@ -1728,29 +1765,31 @@
>           </p>
> 
>         </section>
> -      </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 origin</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>
> +        <section id="exceptions-javascript-api-ww-confirm">
> +          <h3>API to Confirm a Web-wide Exception</h3>
> +
>           <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 origin</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>
> +            <dt>boolean confirmWebWideTrackingException ()
> +            </dt>
>           </dl>
> +          <p>
> +            This API confirms the existence of a
> +            web-wide grant for a specific site, in the database.
> +          </p>
> +          <p>
> +            The returned boolean indicates whether the duplet
> +            <code>[ * , document-origin]</code> exists in the database.
> +          </p>
> +          <ul>
> +            <li><code>true</code> indicates that the web-wide exception exists;</li>
> +            <li><code>false</code> indicates that the web-wide exception 
> +              does not exist.</li>
> +          </ul>
> +        </section>
> 
>       </section>
> -      
> +
> 	  <section id="transitive-exceptions">
> 	    <h2>Transfer of an exception to another third party</h2>
> 	    <p>A site may request an exception for one or more third party services used in 
> @@ -1830,10 +1869,11 @@
>         <p>
>           User agents are free to implement exception management user
>           interfaces as they see fit. Some agents might provide a notification to
> -          the user at the time of the request. Some agents might provide a
> +          the user at the time of the request, or even not complete the storing of
> +          the exception until the user approves. Some agents might provide a
>           user-interface to see and edit the database of recorded exception grants.
>           The API parameters siteName, explanationString, and detailURI are
> -          provided so that the user-agent may use them in this UI.
> +          provided so that the user-agent may use them in their user interface.
>         </p>
>         <p>
>           A user agent that chooses to highlight when tracking exceptions have been 
> @@ -1872,6 +1912,35 @@
>         </p>
>       </section>
> 
> +      <section id="exceptions-no-js" class="informative">
> +        <h2>Exceptions without interactive JavaScript</h2>
> +			<p>Some third party servers that comply with this standard may wish to 
> +			receive user-granted exceptions but when they are invoked as third 
> +			parties (using, for example, images, or "tracking pixels") do not 
> +			have an interactive JavaScript presence on the page. They cannot 
> +			request an exception under these circumstances, both because a 
> +			script is needed, and because they are required to explain to the 
> +			user the need for and consequences of granting an exception, and 
> +			get the user's consent. In general this process of informing, 
> +			getting consent, and calling the API is not expected to be in 
> +			the page where such trackers are invoked.</p>
> +			
> +			<p>To obtain an exception, a document (page, frame, etc.) that 
> +			loads the Javascript is needed. The user may visit the site 
> +			that desires an exception directly, the first party site could 
> +			load a frame of the site desiring the exception, or that frame 
> +			might be part of some other page containing a number of frames, 
> +			which allows aggregation of requests for exceptions.</p>
> +			
> +			<p>In all these ways, the site is contributing to informing the 
> +			user and getting their consent, and is also able to call the 
> +			Javascript API when it is granted.</p>
> +			
> +			<p class="note">Depending on the resolution of options for the 
> +			User-Granted Exceptions section, this language might need to be 
> +			updated to correspond.</p>
> +      </section>
> +
>       <section id="exceptions-when-not-enabled">
>         <h3>Exceptions without a DNT header</h3>
> 
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Wednesday, 16 January 2013 00:35:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 January 2013 00:35:47 GMT