- From: CVS User dsinger2 <cvsmail@w3.org>
- Date: Wed, 16 Jan 2013 00:28:17 +0000
- To: public-tracking-commit@w3.org
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<DOMString> 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>
Received on Wednesday, 16 January 2013 00:28:18 UTC