W3C home > Mailing lists > Public > public-tracking@w3.org > November 2011

TPE site-specific exemption

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 31 Oct 2011 22:34:40 -0700
Message-Id: <5806558E-F200-4134-9E6B-1A71937007D7@gbiv.com>
To: "public-tracking@w3.org WG" <public-tracking@w3.org>
I have switched from using "opt-back-in" to "site-specific exemption".

....Roy

Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- tracking-dnt.html	1 Nov 2011 04:58:17 -0000	1.33
+++ tracking-dnt.html	1 Nov 2011 05:31:26 -0000	1.34
@@ -40,9 +40,8 @@
       honor this preference, both in the form of a machine-readable policy
       at a well-known location for first-party sites and a <q>Tracking<q>
       response header field for third-party resources that engage in
-      cross-site tracking, and a mechanism for allowing the user to
-      selectively opt-back-in for specific sites that require such
-      data collection.
+      cross-site tracking, and a mechanism for allowing the user to approve
+      site-specific exemptions to DNT as desired.
     </section>
 
     <section id="sotd">
@@ -154,8 +153,7 @@
         obtained from targeted advertising and unwilling (or unable) to
         permit use of their content without cross-site data collection,
         we need a mechanism for sites to alert the user to those requirements
-        and allow the user to <q>opt-back-in</q> to tracking for specific
-        sites.
+        and allow the user to configure an exemption to DNT for specific sites.
       </p>
       <p>
         This specification defines the HTTP request header field <a>DNT</a> for
@@ -418,9 +416,9 @@
       <p>
         This section defines how a server communicates its compliance with
         tracking preferences, including whether it will honor the user's
-        preference, require some form of opt-back-in, or believes that it
-        already has the user's permission via some other agreement (e.g.,
-        a subscription or account agreement).  Optionally, links can be
+        preference, require some form of site-specific exemption, or indicate
+        that it already has the user's permission via some other agreement
+        (e.g., a subscription or account agreement).  Optionally, links can be
         provided to human-readable information regarding the site's tracking
         policies or where to go to opt-in, opt-out, or edit their personal
         information.
@@ -441,7 +439,7 @@
             <li>allow user awareness of DNT status per-site/element</li>
             <li>indicate what elements on page have ack'd/honored DNT</li>
           </ul>
-          <li>Help users opt-back-in</li>
+          <li>Guidance for site-specific exemptions</li>
         </ol>
       </section>
 
@@ -480,9 +478,10 @@
           and also some combinations of the above.  For example, we might
           define that compliant servers provide a machine-readable site-wide
           policy that indicates how they honor DNT, what sites are considered
-          the same brand, and links to resources for opt-back-in and editing
-          collected tracking data, and then only provide a dynamic header
-          field response for third-party resources that engage in tracking.
+          the same brand, and links to resources for providing site-specific
+          exemptions to DNT or editing collected tracking data.  We could
+          then limit use of a tracking response header field to only those
+          dynamic responses for third-party resources that engage in tracking.
         </p>
         <p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/81">ISSUE-81</a>: Do we need a response at all from server?<br />
           <strong>[PENDING REVIEW]</strong>
@@ -524,13 +523,11 @@
           <li>sent only on dynamic/tracking responses?</li>
           <li>different on dynamic vs static responses?
               E.g, static headers for elements that never track (like <q>i am neutral</q>) and dynamic headers when <q>I am a tracking element and I accept your choice to not be tracked</q></li>
-          <li>[tl: If sites are doing any sort of opt-back-in behavior,
-              they should be giving that user information about how they
-              are treating that user, so that the user can react
-              appropriately. ... 
+          <li>does it indicate when a site believes it has an exemption from DNT,
+            such that the user can react appropriately if it isn't true. ... 
               The header could say <q>I see that you say DNT, but i am
-              tracking you for the following reasons.</q>]
-          <li>[dsinger: it is sometimes contextual whether you are tracking or not.]
+              tracking you for the following reasons.</q>
+          <li>it is sometimes contextual whether you are tracking or not.
         </ul>
         <p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/76">ISSUE-76</a>: Should a server echo the DNT header to confirm receipt?</p>
         <p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/48">ISSUE-48</a>: Response from the server could both acknowledge receipt of a value and (separately) whether the server will honor it</p>
@@ -542,12 +539,12 @@
 
         <p>An HTTP error response status code might be useful for indicating
           that the site refuses service unless the user either logs into a
-          subscription account or agrees to opt-back-in to tracking for this
+          subscription account or agrees to an exemption to DNT for this
           site and its contracted third-party sites.
       </section>
 
-      <section id='opting-in'>
-        <h2>Selective Opt-back-in</h2>
+      <section id='exemptions'>
+        <h2>Site-specific Exemptions</h2>
         <p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/43">ISSUE-43</a>: Sites should be able to let the user know their options when they arrive with Do Not Track</p>
         <p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/27">ISSUE-27</a>: How should the &quot;opt back in&quot; mechanism be designed?</p>
         <p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/46">ISSUE-46</a>: Enable users to do more granular blocking based on whether the site responds honoring Do Not Track</p>
@@ -581,25 +578,25 @@
     <section id='use-cases'>
       <h3>Use Cases</h3>
 
-      <section id='permanent-opt-back-in'>
-        <h3>Opt-back-in should be persisted</h3>
+      <section id='permanent-exemptions'>
+        <h3>Site-specific exemptions should be persisted</h3>
         
         <p>It would annoy users of DNT if they are presented with an
-        opt-back-in dialog each time they visit a site.</p>
+        exemption dialog each time they visit a site.</p>
         <ol>
           <li>User turns on DNT and visits Example.com</li>
           <li>Example.com does not receive a signal it's on the
-            exceptions list</li>
-          <li>Example.com requests exception from user to access
+            exemption list</li>
+          <li>Example.com requests exemption to DNT from user to access
             content for free</li>
-          <li>User grants exception to Example.com (and perhaps
+          <li>User grants exemption to Example.com (and perhaps
             listed parties)</li>
           <li>User views content</li>
           <li>User returns to Example.com a week later</li>
           <li>DNT signal is still turned on but Example.com is sent an
             exemption flag (or else doesn't send a DNT signal at all)
           <li>In either case, it'll be important that Example.com know
-            to not trigger the exception request for this
+            to not trigger the exemption request for this
             user/web browser/device</li>
         </ol>
       </section>
Received on Tuesday, 1 November 2011 05:35:22 UTC

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