- From: David Singer via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 16 May 2012 14:18:28 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv7868
Modified Files:
tracking-dnt.html
Log Message:
Add the definitions for permitted uses and user-granted exceptions
(though why is it a note?), change "site-specific exception" to
"user-granted exception" in some places, to be consistent. Add a note that there
is no implied cookie handling behavior. Add an issue about cross-origin scripts.
Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.113
retrieving revision 1.114
diff -u -d -r1.113 -r1.114
--- tracking-dnt.html 5 May 2012 06:45:37 -0000 1.113
+++ tracking-dnt.html 16 May 2012 14:18:25 -0000 1.114
@@ -138,7 +138,7 @@
header field <a>Tk</a> for resources to communicate their compliance
or non-compliance with the user's expressed preference, and
JavaScript APIs for determining DNT status and requesting a
- site-specific exception.
+ user-granted exception.
</p>
<p>
A companion document, [[!TRACKING-COMPLIANCE]], more precisely defines
@@ -191,6 +191,18 @@
requests, including, but not limited to, browsers, spiders (web-based robots),
command-line tools, native applications, and mobile apps [[!HTTP11]].
</p>
+ <p class="note">
+ The term <dfn>permitted use</dfn> is used to indicate a restricted set of
+ conditions under which tracking is allowed in spite of the user's DNT
+ preference.
+ The term <dfn>user-granted exception</dfn> is used when the user has
+ permitted tracking,
+ usually in the form of a site-specific exception, for a given third-party.
+ In general:
+ permitted uses are additional permissions granted by the standard;
+ user-granted exceptions are additional permissions granted by the user.
+ These words are often confused when drafting new text.
+ </p>
</section>
</section>
@@ -364,6 +376,9 @@
when enabled, designers of future extensions ought to use as few
extension characters as possible.
</p>
+ <p class="note">This document does not have any implied or specified
+ behavior on the user-agent treatment cookies when when DNT is enabled.
+ </p>
<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/111">ISSUE-111</a>: Different DNT value to signify existence of site-specific exceptions<br />
Should the user agent send a different DNT value to a first party
site if there exist site-specific exceptions for that first party?
@@ -855,8 +870,9 @@
</p>
<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/136">ISSUE-136</a>: Resolve dependencies of the TPE on the compliance specification.<br />
The list of qualifiers is intended to correspond to constraints
- and permitted uses identified by [[!TRACKING-COMPLIANCE]]. The
- above list will be updated accordingly.
+ and permitted uses identified by [[!TRACKING-COMPLIANCE]], and at some point
+ might perhaps even move to that document in the sections defining the
+ permitted uses. The above list will be updated accordingly.
</p>
<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/137">ISSUE-137</a>: Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s)<br />
<b>[PENDING REVIEW]</b> No, a third party that satisfies the
@@ -1198,13 +1214,13 @@
</section>
<section id='exceptions' class="option">
- <h2>Site-specific Exceptions</h2>
- <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/111">ISSUE-111</a>: Different DNT values to signify existence of site-specific exception</p>
+ <h2>User-Granted Exceptions</h2>
+ <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/111">ISSUE-111</a>: Different DNT values to signify existence of site-specific exceptions</p>
<section id="exceptions-overview" class="informative">
<h2>Overview</h2>
<p>
- Exceptions to Do Not Track, including site-specific exceptions, are
+ User-granted exceptions to Do Not Track, including site-specific exceptions, are
managed 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
@@ -1224,8 +1240,8 @@
and use cases</h2>
<p>
- The following principles guide the design of the user-agent-managed
- site-specific exceptions proposal.
+ The following principles guide the design of user-agent-managed
+ exceptions.
</p>
<ul>
<li>Content providers may wish to prompt visitors to their
@@ -1234,7 +1250,7 @@
Track setting enabled.</li>
<li>Privacy-conscious users may wish to view or edit all the
- site-specific exceptions they’ve granted in a single,
+ exceptions they’ve granted in a single,
consistent user interface, rather than managing preferences in a
different way on every content provider or tracker’s privacy
page.</li>
@@ -1305,7 +1321,7 @@
<li>
If requests to the <strong>tracker</strong> for resources that
are part of the DOM for pages on <strong>this site</strong>
- include a DNT header, that header MUST be DNT:OFF.
+ include a DNT header, that header MUST be DNT:0.
</li>
<li>
Responses to the JavaScript API indicated should be consistent
@@ -1320,9 +1336,9 @@
</p>
<p class="issue"><a
href="http://www.w3.org/2011/tracking-protection/track/issues/111">ISSUE-111</a>:
- Different DNT values to signify existence of site-specific
+ Different DNT values to signify existence of user-granted
exception<br /> Should the user agent send a different DNT value to
- a first party site if there exist site-specific exceptions for that
+ a first party site if there exist user-granted exceptions for that
first party? (e.g. DNT:2 implies "I have Do Not Track enabled but
grant permissions to some third parties while browsing this
domain")<br><b>Proposal</b>: No, this API provides client-side means
@@ -1334,7 +1350,7 @@
</section>
<section id="exceptions-javascript-api">
<h2 id="javascript_api_to_prompt_for_exceptions">JavaScript API for
- site-specific exceptions</h3>
+ user-granted exceptions</h3>
<dl class="idl" title='[NoInterfaceObject] interface
NavigatorDoNotTrack'>
<dt>
@@ -1344,7 +1360,7 @@
optional siteName, optional explanationString, optional detailURI)
</dt>
<dd>
- Called by a page to request or confirm a site-specific tracking
+ Called by a page to request or confirm a user-granted tracking
exception.
</dd>
</dl>
@@ -1396,13 +1412,13 @@
<strong>tracker</strong>. The special string “*”
signifies all <strong>trackers</strong>. When called,
<code>requestSiteSpecificTrackingException</code> MUST return
- immediately, then asynchronously determine whether the user wants
+ immediately, then asynchronously determine whether the user grants
the requested exceptions.
</p>
<p>
The <code>granted</code> parameter passed to the callback is the
- user’s response; <code>true</code> indicates the user wants an
+ user’s response; <code>true</code> indicates the user grants an
exception on <strong>this site</strong> for all of the
<strong>tracker</strong>s specified in
<code>arrayOfDomainStrings</code>. The response <code>false</code>
@@ -1467,13 +1483,13 @@
The user agent might then store that decision, and answer future
requests based on this stored preference. User agents might provide
users with granular choice over which tracking origins are granted
- site-specific exceptions and which are not (using checkboxes, for
- example). User agents might automatically clear site-specific
+ exceptions and which are not (using checkboxes, for
+ example). User agents might automatically clear user-granted
exceptions after a period of time or in response to user activity,
like leaving a private browsing mode or using a preference manager
to edit their chosen exceptions. If a user agent retains user
preferences, it might provide the user with an interface to
- explicitly add or remove site-specific exceptions.
+ explicitly add or remove user-granted exceptions.
</p>
<p>
@@ -1505,6 +1521,9 @@
</p>
<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/140">ISSUE-140</a>: Do we need site-specific exceptions, i.e., concrete list of permitted thirdparties for a site?
</p>
+ <p class="issue">We either need to prohibit or document what happens when the
+ source of the script is not <b>this site</b> (same-origin).
+ </p>
</section>
<section id="exceptions-when-not-enabled">
@@ -1563,7 +1582,7 @@
the possibility of fingerprinting during implementation and might
consider rate-limiting requests or using other heuristics to
mitigate fingerprinting risk. User agents SHOULD clear
- stored site-specific exceptions when the user chooses to clear
+ stored user-granted exceptions when the user chooses to clear
cookies or other client-side state.
</p>
</section>
Received on Wednesday, 16 May 2012 14:18:38 UTC