- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Sat, 11 Feb 2012 05:31:01 -0800
- To: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
ACTION-115: Write up counter-proposal to header with well-known URI
Related to ISSUE-124, ISSUE-61, ISSUE-90, ISSUE-111
Here is a proposal for a well-known resource space that covers all
previously agreed considerations for a verifiable response to DNT.
It will be easier to read in the editor's draft.
<section id='status-resource'>
<h3>Tracking Status Resource</h3>
<p class="note">This section is new and untested.</p>
<p>
An origin server MUST provide a space of well-known resources
[RFC5785] for obtaining information about the potential tracking
behavior of each service provided by that origin server. This
parallel tree of resources is called the tracking status resource
space. Failure to provide such a resource space MAY be considered
equivalent to not implementing this protocol.
</p>
<p>
The tracking status resource space is defined by the
following URI Template [RFC_UT_]:
</p>
<pre>/.well-known/dnt{+pathinfo}</pre>
<p>
where the value of <code>pathinfo</code> is equal to the
path-absolute component 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>
MUST have a corresponding tracking status resource identified by
</p>
<pre>http://example.com/.well-known/dnt/over/here</pre>
<p>
A valid retrieval request (e.g., a <code>GET</code> in [HTTP11])
on a tracking status resource MUST result in either a successful
response containing a machine-readable representation of the
corresponding resource's tracking status, as defined below, or
a redirect that leads to such a representation. Failure to provide
access to such a representation MAY be considered equivalent to
not implementing this protocol.
</p>
<p>
A key advantage of providing the tracking status at a resource
separate from the site's normal services is that it can be accessed
and reviewed prior to making use of those services and prior to
making requests on third-party resources referenced by those
services.
All responses to requests on a tracking status resource, including
redirected requests, MUST NOT include Set-Cookie or Set-Cookie2
header fields and MUST NOT include content that has the effect of
initiating additional 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>
<p>
A tracking status resource space MUST be provided for each origin
server involved in providing services for a given site in order for
the service as a whole to be considered conformant to this protocol.
However, access to these resources MAY be redirected to one or more
common resources for provision of the tracking status. If the
redirect is to a prefix of the tracking status URI within the same
resource space, as would be the case for the example above if it
redirected to the
</p>
<pre>http://example.com/.well-known/dnt/</pre>
<p>
URI, then the user agent MAY assume that all resources under that
<code>pathinfo</code> ("/") share the same tracking status.
</p>
<section id='status-representation'>
<h3>Tracking Status Representation</h3>
<p>
The representation of a site's tracking status SHALL be provided
in the "application/json" format [[!RFC4627]] and MUST conform to
the ABNF in <a href="#status-abnf" class="sectionRef"></a>.
The following is an example tracking status representation that
illustrates all of the fields defined by this specification,
most of which are optional.
</p>
<pre class="example">
{
"path": "/",
"tracking": true,
"received": "1",
"response": "t1",
"same-site": [
"example.com",
"example_vids.net",
"example_stats.com"
],
"partners": [
"api.example-third-party.com"
],
"policy": "/tracking.html",
"edit": "http://example-third-party.com/your/data",
"options": "http://example-third-party.com/your/consent"
}
</pre>
<p>
A representation consists of a single <a>status-object</a> that
describes the current tracking status for the corresponding
resource. If the status object has a <code><a>path</a></code>
member, then it also describes the tracking status for the
entire space of resources with the indicated path prefix.
The <code><a>path</a></code> member MAY be elided if the
tracking status applies only to the corresponding resource.
The <code><a>path</a></code> MUST be interpreted relative to the
originally referenced resource even if the tracking status
request has been redirected to a different server.
</p>
<p>
The status object MUST have a member named
<code><a>tracking</a></code> with a boolean value.
A value of <code><a>false</a></code> indicates that the
corresponding resource does not perform tracking as defined by
<q><a href="tracking-compliance.html">Tracking
Compliance and Scope</a></q>.
A value of <code><a>true</a></code> indicates that the
corresponding resource performs tracking and claims to conform to
all tracking compliance requirements applicable to this site.
For example, the following demonstrates a minimal tracking status
representation that is applicable to any resource that does not
perform tracking.
</p>
<pre class="example">
{"tracking": false}
</pre>
<p>
If <code><a>tracking</a></code> is <code><a>true</a></code>,
the status object MUST include two additional members, named
<code><a>received</a></code> and <code><a>response</a></code>,
and MAY include other members as described below.
</p>
<p>
The <code><a>received</a></code> member MUST have either a
string value equal to the <a>DNT-field-value</a> received in that
request or the value <code><a>null</a></code> if no
<a>DNT-field-value</a> was received.
</p>
<p>
The <code></a>response</a></code> member MUST have a string value
that indicates the status of tracking applicable specifically to
this user in light of the received <a>DNT-field-value</a>.
The string value has the following structure:
</p>
<pre class="abnf">
<dfn>r-codes</dfn> = "n" ; tracking disabled
/ ("t" *limitations ) ; tracking enabled
<dfn>limitations</dfn> = "1" ; first-party
/ "c" ; frequency capping
/ "f" ; fraud prevention
/ "r" ; referral tracking
/ ALPHA / DIGIT ; TBD
</pre>
</p>
<p>
An OPTIONAL member named <code><a>same-site</a></code> can be
provided with an array value containing a list of domain names
that the origin server claims are the same site, to the extent
they are referenced on this site, since all data collected via
those references share the same data controller.
</p>
<p>
An OPTIONAL member named <code><a>partners</a></code> can be
provided with an array value containing a list of
domain names for third-party services that might track the user
as a result of using this site and do not have the same
data controller as this site.
</p>
<p>
An OPTIONAL member named <code><a>policy</a></code> can be
provided with a string value containing a URI-reference to a
human-readable document that describes the tracking policy for
this site. The content of such a policy document is beyond the
scope of this protocol and SHOULD ONLY be considered as
supplemental to what is described by this machine-readable
tracking status representation.
</p>
<p>
An OPTIONAL member named <code><a>edit</a></code> can be
provided with a string value containing a URI-reference to a
resource intended to allow a tracked user agent to review or
delete data collected by this site, if any such data
remains associated with this user agent. The design of such
a resource and the extent to which it can provide access to
that data is beyond the scope of this protocol.
</p>
<p>
An OPTIONAL member named <code><a>options</a></code> can be
provided with a string value containing a URI-reference to a
resource intended to allow a user agent to <q>opt-in</q>,
<q>opt-out</q>, or otherwise modify their consent status
regarding data collection by this site. The design of such
a resource and how it might implement an out-of-band consent
mechanism is beyond the scope of this protocol.
</p>
<p>
Additional <code><a>extension</a></code> members MAY be provided
in the tracking status object to support future enhancements to
this protocol. A user agent SHOULD ignore extension members
that it does not recognize.
</p>
<p>
Note that the tracking status resource space applies equally to
both first-party and third-party services. An example of a
third-party tracking status is
<pre class="example">
{
"tracking": true,
"received": "1",
"response": "n",
"policy": "/privacy.html",
"edit": "/your/data",
"options": "/your/consent"
}
</pre>
<p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/47">ISSUE-47</a>: Should the response from the server indicate a policy that describes the DNT practices of the server?</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</p>
</section>
<section id='status-abnf'>
<h3>Tracking Status 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">
<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 ]
*( vs extension )
<dfn>path</dfn> = %x22 "path" %x22
<dfn>path-v</dfn> = string ; URI absolute-path
<dfn>tracking</dfn> = %x22 "tracking" %x22
<dfn>tracking-v</dfn> = true / false
<dfn>received</dfn> = %x22 "received" %x22
<dfn>received-v</dfn> = null / string
<dfn>response</dfn> = %x22 "response" %x22
<dfn>response-v</dfn> = %x22 <a>r-codes</a> %x22
<dfn>same-site</dfn> = %x22 "same-site" %x22
<dfn>same-site-v</dfn> = array-of-strings
<dfn>partners</dfn> = %x22 "partners" %x22
<dfn>partners-v</dfn> = array-of-strings
<dfn>policy</dfn> = %x22 "policy" %x22
<dfn>policy-v</dfn> = string ; URI-reference
<dfn>edit</dfn> = %x22 "edit" %x22
<dfn>edit-v</dfn> = string ; URI-reference
<dfn>options</dfn> = %x22 "options" %x22
<dfn>options-v</dfn> = string ; URI-reference
<dfn>extension</dfn> = object
<dfn>array-of-strings</dfn> = begin-array
[ string *( vs string ) ]
end-array
<dfn>ns</dfn> = <name-separator (:), as defined in [[!RFC4627]]>
<dfn>vs</dfn> = <value-separator (,), as defined in [[!RFC4627]]>
<dfn>begin-array</dfn> = <begin-array ([), as defined in [[!RFC4627]]>
<dfn>end-array</dfn> = <end-array (]), as defined in [[!RFC4627]]>
<dfn>begin-object</dfn> = <begin-object ({), as defined in [[!RFC4627]]>
<dfn>end-object</dfn> = <end-object (}), as defined in [[!RFC4627]]>
<dfn>string</dfn> = <string, as defined in [[!RFC4627]]>
<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>
</section>
<section id='status-caching'>
<h3>Tracking Status Caching</h3>
<p>
If the tracking status is applicable to all users, regardless of
the received DNT-field-value or other data received via the
request, then the response SHOULD be marked as cacheable and
assigned a time-to-live (expiration or max-use) that is sufficient
to enable shared caching but not greater than the earliest point
at which the site's tracking behavior might increase. For example,
if the tracking status response is set to expire in seven days,
then the earliest point in time that the site's tracking behavior
can be increased is seven days after the policy has been updated
to reflect the new behavior, since old copies might persist in
caches until the expiration is triggered. A site's tracking
behavior can be reduced at any time, with or without a
corresponding change to the tracking status resource.
</p>
<p>
If the tracking status is only applicable to all users that have
the same DNT-field-value, then either the response MUST include a
Cache-Control header field with one of the directives "no-cache",
"no-store", "must-revalidate", or "max-age=0", or
the response MUST include a Vary header field that includes "DNT"
in its field-value.
</p>
<p>
If the tracking status is only applicable to the specific user
that requested it, then the response MUST include a
Cache-Control header field with one of the directives "no-cache",
"no-store", "must-revalidate", or "max-age=0".
</p>
<p>
Regardless of the cache-control settings, it is expected that
user agents will check the tracking status of a site only once
per session (at most). A public Internet site that intends to
change its tracking status to increase tracking behavior MUST
update the tracking status resource in accordance with that
planned behavior at least twenty-four hours prior to activating
that new behavior on the site.
</p>
</section>
</section>
Cheers,
Roy T. Fielding <http://roy.gbiv.com/>
Principal Scientist, Adobe Systems <http://adobe.com/enterprise>
Received on Saturday, 11 February 2012 13:31:29 UTC