- From: Roy Fielding via cvs-syncmail <cvsmail@w3.org>
- Date: Sun, 29 Apr 2012 11:01:57 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv22695
Modified Files:
tracking-dnt.html
Log Message:
ACTION-171 Insert the tk/uri hybrid into the tracking-dnt draft.
I merged the hybrid resource/header proposal from Tom's ACTION-145 with various
simplifications to address comments from Heather and JC.
Renamed "same-site" to "same-party" to make it obvious why it exists.
Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.111
retrieving revision 1.112
diff -u -d -r1.111 -r1.112
--- tracking-dnt.html 18 Apr 2012 01:18:04 -0000 1.111
+++ tracking-dnt.html 29 Apr 2012 11:01:54 -0000 1.112
@@ -463,100 +463,115 @@
<section id='responding'>
<h2>Communicating a Tracking Status</h2>
- <div class='note'>
+ <section id='response-overview'>
+ <h3>Overview</h3>
+
<p>
- The next two sections detail two proposals how to communicate
- tracking status:
+ The Tracking Protection protocol is designed to be applicable
+ regardless of the response from servers that receive the tracking
+ preference expression, allowing conformance to be achieved without
+ impacting the operational performance of site resources.
+ However, there is also a desire to support verification or
+ pre-flight testing of a site's conformance with this protocol for
+ evaluating conformance before sending data, enabling specialized
+ user interfaces, discovering the scope of protocol deployment, and
+ testing adherence to potential regulations.
</p>
- <ul>
- <li>Well-known URI to allow user agent to retrieve tracking status
- for a site</li>
- <li>HTTP Response header to communicate tracking status for a
- request</li>
- </ul>
<p>
- This is work in progress. The WG has not yet decided which of these
- options (or both) to choose. The WG is currently working on a
- resolution but nevertheless appreciates input on this open issue.
- We are currently working on a proposal which combines the Tk
- response header and Tracking Status Resource. It would make the TSR
- compulsory and the Tk header optional. However, it would be
- required to use the Tk header to notify the user when something in
- the TSR has changed in real time.
+ This section explains how a user agent MAY discover an origin
+ server's tracking status for a given resource. It defines a
+ REQUIRED well-known <a>tracking status resource</a> for describing
+ a machine-readable tracking status and a <a>Tk</a> response header
+ field that MAY be sent in any HTTP response and MUST be sent in
+ responses to requests that modify the tracking status for that
+ user agent.
</p>
- </div>
+ </section>
- <section id='status-resource' class="option">
+ <section id='status-resource'>
<h3>Tracking Status Resource</h3>
- <section id='status-resource-defn'>
- <h4>Resource Definition</h4>
- <p>
- An origin server MUST provide a <dfn>tracking status resource</dfn>
- at the well-known identifier [[RFC5785]]
- </p>
- <pre>/.well-known/dnt</pre>
- <p>
- (relative to the URI of that origin server) for obtaining information
- about the potential tracking behavior of services provided by
- that origin server. A tracking status resource MAY be used for
- verification of DNT support, as described in
- <a href="#using-tracking-status" class="sectionRef"></a>.
- </p>
- <p>
- A valid retrieval request (e.g., a <code>GET</code> in [[!HTTP11]])
- on the well-known URI MUST result in either a successful response
- containing a machine-readable representation of the site-wide
- tracking status, as defined below, or a sequence of redirects that
- leads to such a representation.
- A user agent MAY consider failure to provide access to such a
- representation equivalent to the origin server not implementing
- this protocol. The representation might be cached, as described
- in <a href="#status-caching" class="sectionRef"></a>.
- </p>
- <p>
- If an origin server contains multiple services that are controlled
- by distinct parties or that might have differing behavior or
- policies regarding tracking, then it MAY also provide a space of
- well-known resources for obtaining information about the potential
- tracking behavior of each specific service. This parallel tree of
- resources is called the <dfn>tracking status resource space</dfn>.
- </p>
- <p>
- The tracking status resource space is defined by the
- following URI Template [[URI-TEMPLATE]]:
- </p>
- <pre>/.well-known/dnt{+pathinfo}</pre>
- <p>
- where the value of <code>pathinfo</code> is equal to the
- path component [[RFC3986]] of a given reference to that
- origin server, excluding those references already within the above
- resource space. For example, a reference to
- </p>
- <pre>http://example.com/over/here?q=hello#top</pre>
- <p>
- MAY have a corresponding tracking status resource identified by
- </p>
- <pre>http://example.com/.well-known/dnt/over/here</pre>
- <p>
- Resources within the tracking status resource space are represented
- using the same format as a site-wide tracking status resource.
- </p>
- <p>
- All requests for well-known URIs defined here MUST NOT be tracked,
- irrespective of the presence, value, or absence of a DNT header,
- cookies, or any other information in the request. In addition, all
- responses to requests on a tracking status resource, including
- redirected requests, MUST NOT include Set-Cookie or Set-Cookie2
- header fields [[COOKIES]] and MUST NOT include content that would
- have the effect of initiating tracking beyond what is already
- present for the request. A user agent SHOULD ignore or treat as an
- error any Set-Cookie or Set-Cookie2 header field received in such a
- response.
- </p>
- </section>
+
+ <section id='status-resource-defn'>
+ <h4>Definition</h4>
+
+ <p>
+ An origin server MUST provide a <dfn>tracking status
+ resource</dfn> at the well-known identifier [[RFC5785]]
+ </p>
+ <pre>/.well-known/dnt</pre>
+ <p>
+ (relative to the URI of that origin server) for obtaining
+ information about the potential tracking behavior of resources
+ provided by that origin server. A tracking status resource MAY be
+ used for verification of DNT support, as described in
+ <a href="#using-tracking-status" class="sectionRef"></a>.
+ </p>
+ <p>
+ A valid retrieval request (e.g., a <code>GET</code> in HTTP)
+ on the well-known URI MUST result in either a successful response
+ containing a machine-readable representation of the site-wide
+ tracking status, as defined below, or a sequence of redirects that
+ leads to such a representation.
+ A user agent MAY consider failure to provide access to such a
+ representation equivalent to the origin server not implementing
+ this protocol. The representation might be cached, as described
+ in <a href="#status-caching" class="sectionRef"></a>.
+ </p>
+ <p>
+ If an origin server contains multiple services that are controlled
+ by distinct parties or that might have differing behavior or
+ policies regarding tracking, then it MAY also provide a space of
+ well-known resources for obtaining information about the potential
+ tracking behavior of each specific service. This parallel tree of
+ resources is called the <dfn>tracking status resource space</dfn>.
+ </p>
+ <p>
+ The <dfn>tracking status resource space</dfn> is defined by the
+ following URI Template [[URI-TEMPLATE]]:
+ </p>
+ <pre>/.well-known/dnt{+pathinfo}</pre>
+ <p>
+ where the value of <code>pathinfo</code> is equal to the
+ path component [[RFC3986]] of a given reference to that
+ origin server, excluding those references already within the above
+ resource space. For example, a reference to
+ </p>
+ <pre>http://example.com/over/here?q=hello#top</pre>
+ <p>
+ MAY have a corresponding tracking status resource identified by
+ </p>
+ <pre>http://example.com/.well-known/dnt/over/here</pre>
+ <p>
+ Resources within the tracking status resource space are
+ represented using the same format as a site-wide tracking status
+ resource.
+ </p>
+ <p>
+ When sending a request for the tracking status, a user agent
+ SHOULD include any cookie data [[COOKIES]] (set prior to the
+ request) that would be sent in a normal request to that origin
+ server, since that data might be needed by the server to determine
+ the current tracking status. For example, the cookie data might
+ indicate a prior out-of-band decision by the user to opt-out or
+ consent to tracking by that origin server.
+ </p>
+ <p>
+ All requests on the tracking status resource space, including
+ the site-wide tracking status resource, MUST NOT be tracked,
+ irrespective of the presence, value, or absence of a DNT header
+ field, cookies, or any other information in the request.
+ In addition, all responses to those requests, including the
+ responses to redirected tracking status requests, MUST NOT
+ have Set-Cookie or Set-Cookie2 header fields and
+ MUST NOT have content that initiates tracking beyond what was
+ already present in the request.
+ A user agent SHOULD ignore, or treat as an error, any Set-Cookie
+ or Set-Cookie2 header field received in such a response.
+ </p>
+ </section>
<section id='status-representation'>
- <h3>Tracking Status Representation</h3>
+ <h3>Representation</h3>
<p>
The representation of a tracking status resource SHALL be provided
in the "application/json" format [[!RFC4627]] and MUST conform to
@@ -571,7 +586,7 @@
"tracking": true,
"received": "1",
"response": "t1",
- "same-site": [
+ "same-party": [
"example.com",
"example_vids.net",
"example_stats.com"
@@ -655,41 +670,14 @@
this user in light of the received <a>DNT-field-value</a>.
The string value begins with "t" (tracking) or "n" (not tracking)
and MAY be followed by alphanumeric characters that indicate
- reasons for that status, as described in the following table.
+ qualifiers for that status.
+ The defined qualifier characters and their meanings are described
+ in <a href="#status-reponse-value" class="sectionRef"></a>.
</p>
- <table class="simple" width="80%" align="center">
- <tr><th>reasons</th>
- <th>meaning</th>
- </tr>
- <tr><td align="middle">1</td>
- <td>Designed for use as a first-party only</td>
- </tr>
- <tr><td align="middle">3</td>
- <td>Designed for use as a third-party<td>
- </tr>
- <tr><td align="middle">a</td>
- <td>Limited to advertising audits<td>
- </tr>
- <tr><td align="middle">c</td>
- <td>Prior consent received from this user agent<td>
- </tr>
- <tr><td align="middle">f</td>
- <td>Limited to fraud prevention<td>
- </tr>
- <tr><td align="middle">g</td>
- <td>For compliance with regional/geographic constraints<td>
- </tr>
- <tr><td align="middle">q</td>
- <td>Limited to advertising frequency capping<td>
- </tr>
- <tr><td align="middle">r</td>
- <td>Limited to referral information<td>
- </tr>
- </table>
<p>
- An OPTIONAL member named <code><a>same-site</a></code> MAY be
+ An OPTIONAL member named <code><a>same-party</a></code> MAY be
provided with an array value containing a list of domain names
- that the origin server claims are the same site, to the extent
+ that the origin server claims are the same party, to the extent
they are referenced on this site, since all data collected via
those references share the same data controller.
</p>
@@ -752,11 +740,11 @@
link to a human-readable policy.
</p>
<p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/61">ISSUE-61</a>: A site could publish a list of the other domains that are associated with them<br />
- <b>[OPEN]</b> The same-site and partners members provide
+ <b>[PENDING REVIEW]</b> The same-party and partners members provide
a means to list first-party and third-party domains, respectively.
</p>
<p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/124">ISSUE-124</a>: Alternative DNT implementations that replace HTTP headers with something else<br />
- <b>[OPEN]</b> The tracking status resource minimizes
+ <b>[PENDING REVIEW]</b> The tracking status resource minimizes
bandwidth usage because only a small proportion of user agents
are expected to perform active verification, status would only be
requested once per site per day, and the response can be
@@ -764,8 +752,122 @@
</p>
</section>
+ <section id='status-response-value'>
+ <h3>Response Value</h3>
+
+ <p>
+ When present, the tracking status response member's value
+ consists of a string of characters that starts with the tracking
+ status, signified by <code>t</code> (tracking) or <code>n</code>
+ (not tracking), and MAY be followed by a set of qualifier
+ characters indicating reasons or limitations applicable to
+ that status. Multiple qualifiers can be provided.
+ </p>
+ <table class="simple" width="80%" align="center">
+ <tr><th>qualifier</th>
+ <th>meaning</th>
+ </tr>
+ <tr><td align="middle">1</td>
+ <td>First-party: The origin server acts as a first-party for
+ requests on this resource, either in all contexts when no
+ "3" qualifier is present or only for the domains listed in
+ <a>same-party</a>.</td>
+ </tr>
+ <tr><td align="middle">3</td>
+ <td>Third-party: The origin server acts as a third-party for
+ requests on this resource, either in all contexts when no
+ "1" qualifier is present or only for the domains not listed
+ in <a>same-party</a>.<td>
+ </tr>
+ <tr><td align="middle">a</td>
+ <td>Audit: Tracking is limited to that necessary for an
+ external audit of the service context and the data
+ collected is minimized accordingly.<td>
+ </tr>
+ <tr><td align="middle">c</td>
+ <td>Ad frequency capping: Tracking is limited to frequency
+ capping and the data collected is minimized accordingly.<td>
+ </tr>
+ <tr><td align="middle">p</td>
+ <td>Prior consent: The origin server believes it has received
+ prior explicit and informed consent for tracking this user,
+ user agent, or device.<td>
+ </tr>
+ <tr><td align="middle">f</td>
+ <td>Fraud prevention: Tracking is limited to that necessary
+ for preventing or investigating fraudulent behavior and
+ security violations; the data collected is minimized
+ accordingly.<td>
+ </tr>
+ <tr><td align="middle">l</td>
+ <td>Local constraints: Tracking is limited to what is
+ required by local law, rule, or regulation and the
+ data collected is minimized accordingly.<td>
+ </tr>
+ <tr><td align="middle">r</td>
+ <td>Referrals: Tracking is limited to collecting referral
+ information and the data collected is minimized
+ accordingly.<td>
+ </tr>
+ </table>
+ <p>
+ Qualifiers that indicate limitations on tracking correspond to
+ the specific permitted uses in [[!TRACKING-COMPLIANCE]]. An
+ origin server indicating one or more of those permitted uses
+ also indicates that it conforms to the requirements associated
+ with those permitted uses. Multiple limitation qualifiers mean
+ that multiple permitted uses of tracking might be present and
+ that each such use conforms to the associated requirements.
+ All limitation qualifiers imply some form of tracking might
+ be used and thus MUST NOT be provided with a tracking status
+ that begins with <code>n</code> (not tracking).
+ </p>
+ <p>
+ A <code>1</code> qualifier indicates that the resource has been
+ designed for use within a first-party context and will conform to
+ the requirements on tracking by a first-party.
+ A <code>3</code> qualifier indicates that the resource has been
+ designed for use within a third-party context and will conform to
+ the requirements on tracking by a third-party.
+ If both qualifiers are present, the resource is designed to
+ dynamically adjust its tracking behavior according to the context
+ in which it is used, and thus conforms to first-party requirements
+ when used in a first-party context and third-party requirements
+ when used in a third-party context.
+ </p>
+ <p>
+ A <code>p</code> qualifier indicates that the origin server
+ believes it has obtained prior explicit and informed consent for
+ tracking the requesting user agent, perhaps via some mechanism
+ not defined by this specification, and that prior consent
+ overrides the tracking preference expressed by this protocol.
+ When prior consent is indicated, the tracking status object
+ SHOULD include an <code><a>options</a></code> member that
+ references a resource for modifying this consent.
+ </p>
+ <p>
+ Future extensions to this protocol might define additional
+ characters as qualifiers from the
+ <code><a>ext-qualifier</a></code> set (consisting of the
+ remaining unused lowercase letters, dot, dash, and underscore).
+ Recipients SHOULD ignore extension qualifiers that they do not
+ understand.
+ </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.
+ </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
+ requirements for acting as a first party will communicate to
+ users as the first party.
+ </p>
+ </section>
+
<section id='using-tracking-status'>
<h3>Using the Tracking Status</h3>
+
<p>
A key advantage of providing the tracking status at a resource
separate from the site's normal services is that the status can
@@ -846,8 +948,8 @@
</p>
<p>
The remaining characters of the <code><a>response</a></code> value
- might indicate reasons for the above choices or limitations that
- the origin server will place on its tracking.
+ might indicate qualifiers for the above choices or limitations
+ that the origin server will place on its tracking.
</p>
<p>
The others members of the <a>status-object</a> MAY be used to
@@ -860,7 +962,7 @@
</section>
<section id='status-caching'>
- <h3>Tracking Status Caching</h3>
+ <h3>Caching</h3>
<p>
If the tracking status is applicable to all users, regardless of
@@ -900,27 +1002,36 @@
planned behavior at least twenty-four hours prior to activating
that new behavior on the service.
</p>
+ <p>
+ A user agent that adjusts behavior based on active verification
+ of tracking status, relying on cached tracking status responses
+ to do so, SHOULD check responses to its state-changing requests
+ (e.g., POST, PUT, DELETE, etc.) for a <a>Tk</a> header field
+ with the <a>update-needed</a> field-value, as described in
+ <a href="#interactive-status-change" class="sectionRef"></a>.
+ </p>
</section>
<section id='status-abnf'>
- <h3>Tracking Status ABNF</h3>
+ <h3>Status-object ABNF</h3>
+
<p>
The representation of a site's machine-readable tracking status
MUST conform to the following ABNF for <a>status-object</a>,
except that the members within each member-list MAY be provided
in any order.
</p>
- <pre class="abnf">
+ <pre class="abnf">
<dfn>status-object</dfn> = begin-object member-list end-object
-<dfn>member-list</dfn> = [ path ns path-v vs ]
- tracking ns tracking-v
- [ vs received ns received-v ]
- [ vs response ns response-v ]
- [ vs same-site ns same-site-v ]
- [ vs partners ns partners-v ]
- [ vs policy ns policy-v ]
- [ vs edit ns edit-v ]
- [ vs options ns options-v ]
+<dfn>member-list</dfn> = [ path ns path-v vs ]
+ tracking ns tracking-v
+ [ vs received ns received-v ]
+ [ vs response ns response-v ]
+ [ vs same-party ns same-party-v ]
+ [ vs partners ns partners-v ]
+ [ vs policy ns policy-v ]
+ [ vs edit ns edit-v ]
+ [ vs options ns options-v ]
*( vs extension )
<dfn>path</dfn> = %x22 "path" %x22
@@ -935,20 +1046,24 @@
<dfn>response</dfn> = %x22 "response" %x22
<dfn>response-v</dfn> = %x22 <a>r-codes</a> %x22
-<dfn>r-codes</dfn> = ("t" / "n") *reasons
+<dfn>r-codes</dfn> = ("t" / "n") *qualifier
-<dfn>reasons</dfn> = "1" ; first-party
- / "3" ; third-party
- / "a" ; advertising audits
- / "c" ; prior consent
- / "f" ; fraud prevention
- / "g" ; geographic/regional compliance
- / "q" ; frequency capping
- / "r" ; referrals
- / ALPHA / DIGIT ; TBD
+<dfn>qualifier</dfn> = "1" ; "1" — first-party
+ / "3" ; "3" — third-party
+ / %x61 ; "a" — audit
+ / %x63 ; "c" — ad frequency capping
+ / %x66 ; "f" — fraud prevention
+ / %x6C ; "l" — local law, rule, or regulation
+ / %x70 ; "p" — prior consent
+ / %x72 ; "r" — referrals
+ / ext-qualifier
-<dfn>same-site</dfn> = %x22 "same-site" %x22
-<dfn>same-site-v</dfn> = array-of-strings
+<dfn>ext-qualifier</dfn> = %x2D-2E / "0" / "2" / %x34-39 / %x5F
+ / %x62 / %x64-65 / %x67-6B / %x6D-%x6F
+ / %x71 / %x73-7A
+
+<dfn>same-party</dfn> = %x22 "same-party" %x22
+<dfn>same-party-v</dfn> = array-of-strings
<dfn>partners</dfn> = %x22 "partners" %x22
<dfn>partners-v</dfn> = array-of-strings
@@ -980,204 +1095,95 @@
<dfn>true</dfn> = <true, as defined in [[!RFC4627]]>
<dfn>false</dfn> = <false, as defined in [[!RFC4627]]>
<dfn>null</dfn> = <null, as defined in [[!RFC4627]]>
- </pre>
+ </pre>
</section>
</section>
- <section id='response-header-field' class="option">
+ <section id='response-header-field'>
<h3>Tk Header Field for HTTP Responses</h3>
- <section id='response-intro'><h4>Motivation</h4>
-
- <p>This specification defines an HTTP response header, in order to meet the following needs:</p>
- <ul>
- <li>User-agents can confirm that the server with which they are
- communicating has received their DNT request.</li>
- <li>User-agents can determine which class of practices the server
- intends to follow when processing this particular request.</li>
- <li>User-agents can determine if a server believes that the user
- has out-of-band consented to let them do additional tracking,
- and may be able to review or modify that consent.</li>
- <li>Servers make a clear promise about how they will process data
- gathered from this particular request.</li>
- <li>Servers have a well-known place to point to more information
- about their tracking/privacy practice.</li>
- <li>Servers can provide customized information to clients if
- desired.</li>
- </ul>
-
- <p>
- An origin server MAY indicate the tracking status for a particular
- request by including a <a>Tk</a> header field in the corresponding
- response. If a request contains a <a>DNT-field-value</a> starting
- with "1", an origin server SHOULD send a <a>Tk</a> header field in
- the corresponding response.
- </p>
-
- <p>
- If an origin server chooses not to send a Tk header field, then
- the user agent will not know if the tracking preference has been
- received or if it will be honored. This may have negative
- consequences for the site, such as triggering preventive measures
- on the user agent or being flagged as non-compliant by tools that
- look for response header fields.
- </p>
- <p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/107">ISSUE-107</a>: Exact format of the response header?<br />
- <b>[OPEN]</b> See the proposal in this section.
- </p>
-
- <p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/120">ISSUE-120</a>: Should the response header be mandatory (MUST) or recommended (SHOULD)</br>
- <b>[OPEN]</b> Text in above paragraphs.
- </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)?
- </p>
-
- </section>
- <section id='response-abnf'><h4>Tk ABNF</h4>
- <p>
- The <dfn>Tk</dfn> header field is defined as follows:
- </p>
- <pre class="abnf">
- <dfn>Tk-Response</dfn> = "Tk:" [CFWS] Tk-Status [CFWS] [ opt-in-flag ] [CFWS] [ reason-code ]
- <dfn>Tk-Status</dfn> = no-dnt
- / not-tracking
- / first-party
- / service-provider
- <dfn>no-dnt</dfn> = "0"
- <dfn>not-tracking</dfn> = "1"
- <dfn>first-party</dfn> = %x66 ; lowercase f
- <dfn>service-provider</dfn> = %x73 ; lowercase s
- <dfn>opt-in-flag</dfn> = "1"
- <dfn>reason-code</dfn> = ALPHA
- </pre>
- </section>
-
- <section id='response-meaning'><h4>Tk Semantics</h4>
- <p>
- <b>Tk: 0</b> (<a>no-dnt</a>) indicates that this party does not
- comply with [[!TRACKING-COMPLIANCE]].
- </p>
- <p>
- <b>Tk: 1</b> (<a>not-tracking</a>) indicates that:
- </p>
- <ul>
- <li>this party complies with [[!TRACKING-COMPLIANCE]],
- and</li>
- <li>this party will process this request according to the
- specification for 3rd parties in [[!TRACKING-COMPLIANCE]].
- </ul>
- <p>
- <b>Tk: f</b> (<a>first-party</a>) indicates that:
- </p>
- <ul>
- <li>this party complies with [[!TRACKING-COMPLIANCE]],</li>
- <li>this resource is intended to be served as a first party, and</li>
- <li>this party will process this request according to the
- specifications for 1st parties in [[!TRACKING-COMPLIANCE]].</li>
- </ul>
- <p>
- <b>Tk: s</b> (<a>service-provider</a>) indicates that:
- </p>
- <ul>
- <li>this party complies with [[!TRACKING-COMPLIANCE]],</li>
- <li>this resource is intended to be used in the context of third party acting as an outsourced service provider for a first party, and</li>
- <li>this party will process this request according to the exemption
- for a third party acting as an outsourced service provider for a
- first party, as described in [[!TRACKING-COMPLIANCE]].</li>
- </ul>
- <p>
- The <a>opt-in-flag</a> indicates that the server believes that the
- user has affirmatively consented to allow this party additional
- permission to track them. Unless the <a>opt-in-flag</a> is included,
- the server asserts that will act in responding to this request as if
- the user has not affirmatively consented to allow this party
- additional permission to track them.
- </p>
- <p>
- The <a>reason-code</a> can be used when requesting more information (see below).
- </p>
- </section>
-
- <section id='response-more'><h4>More Information</h4>
+ <section id='Tk-header-defn'>
+ <h4>Definition</h4>
- <p>If a <a>reason code</a> is specified in the response, the well-known resource defined here MUST exist; if an <a>opt-in-flag</a> is included, the wel--known resource defined here SHOULD exist; otherwise it MAY exist.</p>
-
- <p>The user can understand and manage their
- opt-in by visiting the well-known URI
- <pre>/.well-known/dnt?status={Tk-status}&opt-in={opt-in-flag}&r={reason-code}</pre>
- relative to the request-target.
- </p>
- <p>
- The information at this URI provides additional information about this party's privacy practices and practices, particularly concerning the <a>opt-in-flag</a>.
- </p>
-
- <p class="note">
- The above well-known URI has not yet been reconciled with the
- similar but distinct definition for the tracking status
- resource. We anticipate that one or the other will be adopted,
- or the two proposals will be merged.
- </p>
-
+ <p>
+ As a supplement to the tracking status resource, the <dfn>Tk</dfn>
+ response header field is defined as an OPTIONAL means for
+ indicating basic tracking behavior and as a REQUIRED means for
+ indicating that a state-changing request has resulted in an
+ interactive change to the tracking status for this user agent.
+ </p>
+ <pre class="abnf">
+<dfn>Tk-field-name</dfn> = "Tk" ; case-insensitive
+<dfn>Tk-field-value</dfn> = tracking-false / tracking-true / update-needed
+<dfn>tracking-false</dfn> = "0"
+<dfn>tracking-true</dfn> = "1"
+<dfn>update-needed</dfn> = %x75 ; lowercase "u"
+ </pre>
+ <p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/107">ISSUE-107</a>: Exact format of the response header?<br />
+ <b>[PENDING REVIEW]</b> See the proposal in this section.
+ </p>
</section>
- <section id='response-impl'><h4>Implementation and Usage Considerations</h4>
-
+ <section id='Tk-header-use'>
+ <h4>Indicating Tracking</h4>
+
<p>
- Implementers should use caution when allowing caching of resources
- on which an opt-in flag is included. If caching is not carefully
- managed, there is a risk of sending a response intended for
- opted-in users to users who haven't opted in.
+ An origin server MAY send a <a>Tk</a> header field in a response
+ with a field-value of "0" to indicate that the resource does not
+ perform tracking as it is defined by [[!TRACKING-COMPLIANCE]].
+ This has the same meaning as <code>{"tracking": "false"}</code>
+ in the tracking status resource.
</p>
+ <pre class="example">
+Tk: 0
+ </pre>
<p>
- Implementers should carefully choose the cache properties of the
- items at the well-known URI. The content at these locations must
- be correct for the entire cache duration, otherwise users who load
- stale cached copies of these resources may be misled.
+ An origin server MAY send a <a>Tk</a> header field in a response
+ with a field-value of "1" to indicate that the resource does
+ perform tracking, though not necessarily for this request, and
+ claims to conform to applicable tracking compliance requirements.
+ This has the same meaning as <code>{"tracking": "true"}</code>
+ in the tracking status resource.
</p>
- <p>
- Any party can use the <a>not-tracking</a> response: this response
- just indicates a behavior. If a first party complies with the
- third-party definition, they are free to send this response.
- However, the <a>first-party</a> and <a>service provider</a>
- responses indicate both a behavior and an intention about that
- party's status. It would be deceptive to send the <a>first-party</a>
- header on a resource which is only ever embedded as a third party.
+ <pre class="example">
+Tk: 1
+ </pre>
+ <p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/120">ISSUE-120</a>: Should the response header be mandatory (MUST) or recommended (SHOULD)</br>
+ <b>[PENDING REVIEW]</b> The resource is mandatory and the header
+ field is optional, except for the single MUST case below.
</p>
+ </section>
+
+ <section id='interactive-status-change'>
+ <h4>Indicating an Interactive Status Change</h4>
+
<p>
- The <a>no-dnt</a> response should not be used on requests which
- are processed in accordance with [[!TRACKING-COMPLIANCE]].
- An entity which implements DNT should not use this response.
+ We anticipate that interactive mechanisms might be used, beyond
+ the scope of this specification, that have the effect of asking
+ for and obtaining prior consent for tracking, or for modifying
+ prior indications of consent. For example, the tracking status
+ resource's status-object defines <code><a>edit</a></code> and
+ <code><a>options</a></code> members that might be used to refer
+ to such mechanisms. Although such mechanisms are not defined by
+ this specification, their presence might influence the tracking
+ status object's response value.
</p>
<p>
- When embedding content from other sites, consider how that site
- expects their content to be used. If you embed/link to an
- object on another site, it's possible that the resource will send
- a <a>first-party</a> response even though it is now in a
- third-party context because the designer of that site never
- intended that object to be embedded. If a resource always sends a
- <a>third-party</a> response, there is no risk of this inconsistent
- response. Only the first-party outsourcer of
- <a>service-provider</a> objects should ever embed them.
+ When an origin server provides a mechanism via HTTP for
+ establishing or modifying out-of-band tracking preferences,
+ the origin server MUST indicate within the mechanism's response
+ when a state-changing request has resulted in a change to the
+ tracking status for that server. This indication of an
+ interactive status change is accomplished by sending a
+ <a>Tk</a> header field in the response with a field-value of
+ lowercase "u" (<a>update-needed</a>).
</p>
+ <pre class="example">
+Tk: u
+ </pre>
</section>
- <section id='response-example'><h4>Examples</h4>
- <pre class="example">
-Tk: 1
- </pre>
- <p>
- The site is a third or first party, in compliance with the definitions of a 3rd party that is not tracking.
- </p>
- <pre class="example">
-Tk: 1 1 agreed
- </pre>
- <p>
- The site is a third party, that believes it has an explicit opt-in from the user; more information can be found at:
- <pre>/.well-known/dnt?status=1&opt-in=1&r=agreed</pre>
- </p>
- </section>
- </div>
</section>
-
+
<section id='response-error'>
<h3>Status Code for Tracking Required</h3>
Received on Sunday, 29 April 2012 11:02:01 UTC