- From: CVS User dsinger2 <cvsmail@w3.org>
- Date: Fri, 07 Dec 2012 00:26:44 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory gil:/tmp/cvs-serv329
Modified Files:
tracking-dnt.html
Log Message:
Changes the exception model to that requested by Adrian and Ian, to be
UA-UI-free.
Previous version snapshotted at tracking-dnt-20121206.html
--- /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 2012/11/20 01:33:07 1.173
+++ /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 2012/12/07 00:26:44 1.174
@@ -39,7 +39,7 @@
honor this preference, both in the form of a machine-readable tracking
status resource at a well-known location and via a <q>Tk</q>
response header field, and a mechanism for allowing the user to approve
- site-specific exceptions to DNT as desired.
+ exceptions to DNT as desired.
</p>
</section>
@@ -198,8 +198,7 @@
</p>
<p>
The term <dfn>user-granted exception</dfn> is used when the user has
- permitted tracking by a given third party, usually in the form of a
- site-specific exception.
+ permitted tracking by a given third party.
</p>
<p>
A companion document, [[!TRACKING-COMPLIANCE]], defines many of the
@@ -220,9 +219,10 @@
all parties.
</p>
<p>
- Key to that notion of expression is that it MUST reflect the user's
- preference, not the choice of some vendor, institution, or
- network-imposed mechanism outside the user's control. The basic
+ Key to that notion of expression is that the signal sent MUST reflect the user's
+ preference, not the choice of some vendor, institution, site, or any
+ network-imposed mechanism outside the user's control; this applies
+ equally to both the general preference and exceptions. The basic
principle is that a tracking preference expression is only
transmitted when it reflects a deliberate choice by the user.
In the absence of user choice, there is no tracking preference
@@ -357,7 +357,7 @@
The DNT field-value sent by a user agent MUST begin with the
numeric character "1" (%x31) if a tracking preference is
<a>enabled</a>, the preference is for no tracking, and
- there is not a site-specific exception for the origin server
+ there is not an exception for the origin server
targeted by this request.
</p>
<p>
@@ -421,6 +421,9 @@
<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>
@@ -1283,19 +1286,13 @@
<h2>Overview</h2>
<p>
User-granted exceptions to Do Not Track, including site-specific
- exceptions, are managed by the user agent. A resource should rely on
+ exceptions, are agreed between the site and the user, and stored
+ by the user agent. A resource should rely on
the DNT header it receives to determine the user's preference for
tracking with respect to that particular request. An API is provided
so that sites may request and check the status of exceptions for
tracking.
</p>
- <p>
- We anticipate that many user-agents might provide a prompt to users
- when this API is used, or to store exceptions. Questions of user
- interface specifics — for granting, configuring, storing,
- syncing and revoking exceptions — are explicitly left open to
- implementers.
- </p>
<p class="issue" data-number="144" title="What constraints on user agents should be imposed for user/granted exceptions">
<b>[OPEN]</b> but mostly addressed in the proposal here.
@@ -1348,9 +1345,46 @@
<section id='exception-model'>
<h2>Exception model</h2>
-
<section>
- <h3>Introduction</h3>
+ <h3>User Interaction</h3>
+ <p>
+ The call to store an exception MUST reflect the user's intention to grant
+ an exception, at the time of the call. This intention MUST be determined by
+ the site prior to each call to store an exception, at the time of
+ the call. (This allows
+ the user to change their mind, and delete a stored exception, which might
+ then trigger the site to explain, and ask for, the exception again).
+ </p>
+ <p>
+ Sites MAY ask for an exception, and have it stored, even when the user's
+ general preference is not <a>enabled</a>.
+ (This permits recording a permission
+ to allow tracking in jurisdictions where such permission cannot be
+ assumed.)
+ </p>
+ <p>
+ The user-agent MAY provide interfaces to the user:
+ <ul>
+ <li>To indicate that a call to store an exception has just been made;</li>
+ <li>To indicate that one or more exceptions exist for the current
+ top-level origin;</li>
+ <li>To indicate that one or more exceptions exist for sites
+ incorporated into the current page;</li>
+ <li>To allow the user to see and possibly revoke stored exceptions.</li>
+ <li>Other aspects of the exception mechanism, as desired.</li>
+ </ul>
+ There is no required user-interface for the user-agent.
+ </p>
+ <p class="note">
+ The requirement for the site to determine the user's intention is new;
+ previously the site was required to inform, but the final
+ determination of intention was the responsibility of the UA. This
+ version removes that split of user-determination, and leaves it
+ solely with the site.
+ </p>
+ </section>
+ <section>
+ <h3>Processing Model</h3>
<p>
This section describes the effect of the APIs in terms of a
logical processing model; this model describes the behavior, but
@@ -1424,9 +1458,7 @@
The calls cause the following steps to occur:
</p>
<ul>
- <li>First, the UA somehow confirms with the user that they agree
- to the grant of exception, if not already granted;</li>
- <li>If they agree, then the UA adds to its local database one or
+ <li>The UA adds to its local database one or
more site-pair duplets [document-origin, target]; one or other
of these may be a wild-card ("*");</li>
<li>While the user is browsing a given site (top-level origin),
@@ -1436,10 +1468,9 @@
sent.</li>
</ul>
<p class="note">
- Note that a site may record that it has previously asked for, and been
- denied, an exception, if it wishes to avoid repeatedly asking the user
- for an exception.
- </p>
+ The prior version of this required that the UA "somehow confirms with the
+ user that they agree to the grant of exception, if not already granted"
+ </p>
</section>
<section id='exception-use-browsers'>
@@ -1470,18 +1501,12 @@
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 granted, and later remove only one or
+ targets {a, b, c} has been stored, 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
to an API is a separate unit.
</p>
- <p>
- When a user-agent receives an API request for an exception that
- already exists (i.e. the grant is recorded in its database), it SHOULD
- bypass asking the user to confirm, and simply re-confirm the grant
- to the caller.
- </p>
<div class="note">
<p>
It is left up to individual user-agent implementations how to
@@ -1491,16 +1516,16 @@
<p>
When an explicit list of domains is provided through the API,
their names might mean little to the user. The user might, for
- example, be told that such-and-such top-level origin is asking
- for an exception for a specific set of sites, rather than
- listing them by name; or the user-agent may decide to ask the
- user for a site-wide exception, effectively ignoring the list of
+ example, be told that there is a stored exception for a specific set
+ of sites on such-and-such top-level origin, rather than listing them
+ by name; or the user-agent may decide to store, and show to the user,
+ a site-wide exception, effectively ignoring the list of
domain names, if supplied.
</p>
<p>
- Conversely, if a wild-card is used, the user may be told that
- the top-level origin is asking for an exception for all
- third-parties that are, or will be, embedded in it.
+ Conversely, if a wild-card is used, the user may be told that there is
+ a stored exception for all third-parties that are, or will be, embedded
+ on the indicated the top-level origin.
</p>
</div>
@@ -1530,36 +1555,21 @@
<h3>API to request site-specific exceptions</h3>
<dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
- <dt>void requestSiteSpecificTrackingException (
- in TrackingResponseCallback callback,
+ <dt>integer storeSiteSpecificTrackingException (
optional sequence<DOMString> arrayOfDomainStrings,
optional siteName,
optional explanationString,
optional detailURI)
</dt>
<dd>
- Called by a page to request or confirm a user-granted tracking
+ Called by a page to store a site-specific tracking
exception.
</dd>
</dl>
- <dl class="idl" title='[Callback, NoInterfaceObject] interface TrackingResponseCallback'>
- <dt>void handleEvent(in integer granted)</dt>
- <dd>
- The callback is called by the user agent to indicate the user's
- response.
- </dd>
- </dl>
- <p>
- The <code>requestSiteSpecificTrackingException</code> method takes
- one mandatory argument:
- </p>
- <ul>
- <li><code>callback</code>, a method that will be called when the
- request is complete.</li>
- </ul>
<p>
- It also takes four optional arguments:
+ The <code>storeSiteSpecificTrackingException</code> method takes
+ four optional arguments:
</p>
<ul>
<li><code>arrayOfDomainStrings</code>, a JavaScript array of
@@ -1578,14 +1588,13 @@
<code>arrayOfDomainStrings</code> specifies a
<strong>target</strong>. When called,
<code>requestSiteSpecificTrackingException</code> MUST return
- immediately, then asynchronously determine whether the user grants
- the requested exception(s).
+ immediately.
</p>
<p>
If the list <code>arrayOfDomainStrings</code> is supplied, the
- user-agent MAY choose to ask the user to grant a site-wide
- exception. If it does so, and the user agrees, it MUST indicate
- this in the response callback.
+ user-agent MAY choose to store a site-wide
+ exception. If it does so it MUST indicate
+ this in the return value.
</p>
<p>
The execution of this API and the use of the resulting permission
@@ -1595,24 +1604,21 @@
compared with the <strong>top-level origin</strong>.
</p>
<p>
- The <code>granted</code> parameter passed to the callback is the
- user's response; The response
+ The returned integer has the following possible values:
</p>
<ul>
- <li><code>0</code> indicates that user does not grant the
- exception on <strong>top-level origin</strong> for the indicated
- <strong>target</strong>s.</li>
+ <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 grants an exception on
+ <strong>target</strong>s and the the user-agent has stored an exception on
<strong>top-level origin</strong> for those specific
<strong>target</strong>s.</li>
- <li><code>2</code> indicates the user grants a site-wide exception
+ <li><code>2</code> indicates the user-agent has stored 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>
<p>
- If permission is granted for an explicit list, then the set of
+ If permission is stored for an explicit list, then the set of
duplets (one per target):
</p>
<pre>[document-origin, target]</pre>
@@ -1620,7 +1626,7 @@
is added to the database of remembered grants.
</p>
<p>
- If permission is granted for a site-wide exception, then the
+ If permission is stored for a site-wide exception, then the
duplets:
</p>
<pre>[document-origin, * ]</pre>
@@ -1629,13 +1635,14 @@
</p>
<p>
A particular response to the API — like a DNT response
- header — is only valid immediately, and users' preferences
- may change.
+ header — is only valid immediately, and users may choose to
+ edit the list of stored exceptions and revoke some or all of them.
</p>
- <p>
- A user agent MAY use an interactive method to ask the user about
- their preferences, so sites SHOULD NOT assume that the callback
- function will be called immediately.
+ <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.
</p>
</section>
@@ -1655,8 +1662,8 @@
</dd>
</dl>
<p>This returns a boolean indicating, when true, that the call has
- succeeded, and that the database of grants no longer contains,
- or very soon will no longer contain, the indicated grant(s); when false,
+ succeeded, and that the database of grants no longer contains
+ the indicated grant(s); when false,
some kind of processing error occurred.
</p>
</section>
@@ -1669,14 +1676,13 @@
<h3>API to Request a Web-wide Exception</h3>
<dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
- <dt>void requestWebWideTrackingException (
- in TrackingResponseCallback callback,
+ <dt>integer storeWebWideTrackingException (
optional siteName,
optional explanationString,
optional detailURI)
</dt>
<dd>
- If permission is granted, then the single duplet
+ The single duplet
<code>[ * , document-origin]</code>
is added to the database of remembered grants.
The parameters are as described
@@ -1685,10 +1691,20 @@
</dd>
</dl>
<p>
- Users may wish to configure exceptions for a certain trusted
- tracker across all sites. This API requests the addition of a
+ This API requests the addition of a
web-wide grant for a specific site, to the database.
</p>
+ <p>
+ The returned integer has the following possible values:
+ </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>
+ </ul>
+ <p class="note">
+ As above, this call used to be asynchronous, and the change to the UI
+ enabled it to be sycnhronous.
+ </p>
</section>
<section id="exceptions-javascript-api-ww-cancel">
@@ -1706,8 +1722,8 @@
</dd>
</dl>
<p>This returns a boolean indicating, when true, that the call has
- succeeded, and that the database of grants no longer contains,
- or very soon will no longer contain, the indicated grant; when false,
+ succeeded, and that the database of grants no longer contains
+ the indicated grant; when false,
some kind of processing error occurred.
</p>
@@ -1801,57 +1817,39 @@
<h2>User interface guidelines</h2>
<p>
- User agents are free to implement exception management user
- interfaces as they see fit. Some agents might provide a prompt to
- the user at the time of the request. Some agents might allow users
- to configure this preference in advance. In either case, the user
- agent responds with the user's preference.
- </p>
- <p>
- In general, it is expected that the site will explain, in its online
- content, the need for an
- exception, and the consequences of granting or denying an exception, to
- the user, and guide. The call to the API and the resulting request for
- user confirmation should not be a 'surprise' to the user, or require
- much explanation on the part of the user-agent.
- </p>
- <p>
- A user agent that chooses to implement a prompt to present tracking
- exception requests to the user might provide an interface like the
- following:
+ As described above, it is the responsibility solely of the
+ site making the call to determine that an exception
[63 lines skipped]
Received on Friday, 7 December 2012 00:26:47 UTC