- From: CVS User rfieldin <cvsmail@w3.org>
- Date: Thu, 28 Nov 2013 03:03:55 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory gil:/tmp/cvs-serv12106
Modified Files:
tracking-dnt.html
Log Message:
Initial pass at removing all dependencies on a single compliance document
--- /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 2013/10/23 23:32:18 1.225
+++ /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 2013/11/28 03:03:55 1.226
@@ -24,15 +24,29 @@
wgPatentURI: "http://www.w3.org/2004/01/pp-impl/49311/status",
issueBase: "http://www.w3.org/2011/tracking-protection/track/issues/",
localBiblio: {
- "TRACKING-COMPLIANCE": {
- "authors": ["Heather West","Justin Brookman","Sean Harvey","Erica Newland"],
- // "status" : "WD",
- // "href" : "http://www.w3.org/TR/tracking-compliance/",
- "status" : "ED",
- "href" : "http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html",
- "title" : "Tracking Compliance and Scope",
- "date" : "01 October 2013",
- "publisher" : "W3C"
+ "HTTP" : {
+ "title" : "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
+ "authors": ["Roy T. Fielding", "Julian Reschke"],
+ "status" : "Internet-Draft",
+ "date" : "17 November 2013",
+ "publisher" : "IETF",
+ "href" : "http://datatracker.ietf.org/doc/draft-ietf-httpbis-p1-messaging/"
+ },
+ "HTTP-semantics" : {
+ "title" : "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content",
+ "authors": ["Roy T. Fielding", "Julian Reschke"],
+ "status" : "Internet-Draft",
+ "date" : "17 November 2013",
+ "publisher" : "IETF",
+ "href" : "http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics/"
+ },
+ "HTTP-cache" : {
+ "title" : "Hypertext Transfer Protocol (HTTP/1.1): Caching",
+ "authors": ["Roy T. Fielding", "Mark Nottingham", "Julian Reschke"],
+ "status" : "Internet-Draft",
+ "date" : "17 November 2013",
+ "publisher" : "IETF",
+ "href" : "http://datatracker.ietf.org/doc/draft-ietf-httpbis-p1-cache/"
}
},
noIDLSectionTitle: true
@@ -43,15 +57,14 @@
<body>
<section id='abstract'>
<p>
- This specification defines the technical mechanisms for expressing a
- tracking preference via the <a>DNT</a> request header field in
- HTTP, via an HTML DOM property readable by embedded scripts, and via
- properties accessible to various user agent plug-in or extension APIs.
- It also defines mechanisms for sites to signal whether and how they
- 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
- exceptions to DNT as desired.
+ This specification defines the <a>DNT</a> request header field as an
+ HTTP mechanism for expressing the user's preference regarding tracking,
+ an HTML DOM property to make that expression readable by scripts, and
+ APIs that allow scripts to register site-specific exceptions granted by
+ the user. It also defines mechanisms for sites to communicate whether
+ and how they honor a received preference through use of the <q>Tk</q>
+ response header field and well-known resources that provide a
+ machine-readable tracking status.
</p>
</section>
@@ -76,6 +89,9 @@
<a href="http://www.w3.org/2011/tracking-protection/track/issues/postponed">postponed</a>
issues regarding this document.
</p>
+ <p class="issue" data-number="136" title="Resolve dependencies of the TPE on the compliance specification">
+ [OPEN] This draft removes all dependencies on TCS.
+ </p>
</section>
<section>
@@ -96,13 +112,12 @@
<p>
Each of the hypertext actions and each of the embedded resource
references might refer to any site on the Web, leading to a seamless
- interaction with the user even though the pages might be composed of
+ interaction with the user even when a pages might be composed of
information requested from many different and possibly independent
Web sites. From the user's perspective, they are simply visiting and
- interacting with a single brand — the <dfn>first-party</dfn> Web
- property — and all of the technical details and protocol mechanisms
- that are used to compose a page representing that brand are hidden
- behind the scenes.
+ interacting with a single Web property: all of the technical details
+ and protocol mechanisms used to compose a page to represent that
+ property are hidden behind the scenes.
</p>
<p>
It has become common for Web site owners to collect data regarding
@@ -128,44 +143,26 @@
contexts, others are troubled by what they perceive as an invasion of
their privacy. For them, the benefit of personalization is not worth
their concerns about allowing entities with whom they have no direct
- relationship to amass detailed profiles about their activities.
+ relationship to amass profiles about their activities.
</p>
<p>
Therefore, users need a mechanism to express their own preference
regarding tracking that is both simple to configure and efficient
when implemented. In turn, Web sites that are unwilling or unable to
- offer content without such targeted advertising or data collection
- need a mechanism to indicate those requirements to the user and allow
- them (or their user agent) to make an individual choice regarding
- exceptions.
+ offer content without such data collection need a mechanism to
+ indicate that status to the user and allow them (or their user agent)
+ to make an individual choice regarding exceptions.
</p>
<p>
- This specification defines the HTTP request header field <a>DNT</a> for
- expressing a tracking preference on the Web, a well-known location
- (URI) for providing a machine-readable
- <a href="#status-resource">tracking status resource</a>
- that describes a service's DNT compliance, the HTTP response
- 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
+ This specification defines protocol elements for use within the
+ Hypertext Transfer Protocol [[!HTTP]] which allow a user to express a
+ tracking preference, via the <a>DNT</a> request header field, and
+ allow a server to describe their tracking behavior via a well-known
+ <a href="#status-resource">tracking status resource</a> and the
+ <a>Tk</a> response header field. In addition, JavaScript APIs are
+ defined for enabling scripts to determine DNT status and to register a
user-granted exception.
</p>
- <p>
- A companion document, [[!TRACKING-COMPLIANCE]], more precisely defines
- the terminology of tracking preferences, the scope of its
- applicability, and the requirements on compliant first-party and
- third-party participants when an indication of tracking preference
- is received.
- </p>
- <p class="issue" data-number="136" title="Resolve dependencies of the TPE on the compliance specification">
- [OPEN] The WG has not come to consensus regarding the definition of tracking
- and the scope of DNT. As such, a site cannot actually say with any
- confidence whether or not it is tracking, let alone describe the finer
- details in a tracking status resource. This issue will be resolved by
- progress on the TCS document, though its resolution is a
- necessary prerequisite to understanding and correctly implementing
- the protocol defined by this document.
- </p>
</section>
<section id='notational'>
@@ -181,8 +178,8 @@
<em title="recommended" class="rfc2119">recommended</em>,
<em title="may" class="rfc2119">may</em>, and
<em title="optional" class="rfc2119">optional</em> in this
- specification are to be interpreted as described in
- [[!RFC2119]].</p>
+ specification are to be interpreted as described in [[!RFC2119]].
+ </p>
</section>
<section id='notation'>
@@ -201,21 +198,12 @@
any of the various client programs capable of initiating HTTP
requests, including, but not limited to, browsers, spiders
(web-based robots), command-line tools, native applications, and
- mobile apps [[!HTTP11]].
- </p>
- <p>
- 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.
+ mobile apps [[!HTTP]].
</p>
<p>
The term <dfn>user-granted exception</dfn> is used when the user has
permitted tracking by a given third party.
</p>
- <p>
- A companion document, [[!TRACKING-COMPLIANCE]], defines many of the
- terms used here, notably 'party', 'first party', and 'third party'.
- </p>
</section>
</section>
@@ -362,7 +350,7 @@
<p>
The <dfn>DNT</dfn> header field is hereby defined as the means for
- expressing a user's tracking preference via HTTP [[!HTTP11]].
+ expressing a user's tracking preference via HTTP [[!HTTP]].
</p>
<pre class="abnf">
<dfn>DNT-field-name</dfn> = "DNT"
@@ -435,10 +423,8 @@
<p class="note">This document does not have any implied or specified
behavior for the user agent treatment of cookies when DNT is enabled.
</p>
- <p class="note">The HTTP specification [[!HTTP11]] permits multiple headers
- with the same field-name only under restricted circumstances which do
- not apply here; hence, at most one DNT header may be present in a valid
- HTTP request.
+ <p class="note">At most one DNT header can be present in a valid HTTP
+ request [[!HTTP]].
</p>
<p class="issue" data-number="176" title="Requirements on intermediaries/isps and header insertion that might affect tracking">[OPEN]</p>
@@ -490,22 +476,11 @@
<h3>Tracking Preference Expressed in Other Protocols</h3>
<p>
- A user's tracking preference is intended to apply in general,
- regardless of the protocols being used for Internet communication.
- The protocol expressed here is specific to HTTP communication;
- however, the semantics are not restricted to use in HTTP; the same
- semantics may be carried by other protocols, either in future
- revisions of this specification, or in other specifications.
- </p>
- <p>
- When it is known that the user's preference is for no tracking,
- compliant services are still required to honor that preference, even
- if other protocols are used. For example, redirecting to another
- protocol in order to avoid receipt of the header is not compliant.
- </p>
- <p class='note'>
- The last paragraph may be more appropriate in the compliance
- document, as it discusses compliance.
+ It is beyond the scope of this specification to define how a user's
+ tracking preference might be communicated via protocols other than
+ HTTP. However, the semantics of a user's tracking preference is
+ intended to apply in general, regardless of the protocols being used
+ for Internet communication.
</p>
</section>
</section>
@@ -517,20 +492,14 @@
<h3>Overview</h3>
<p>
- The primary goals of this protocol—expressing the user's preference
- and adhering to that preference—can be accomplished without any
- response from the server. However, the protocol also seeks to
- improve the transparency of tracking behavior by providing a
- machine-readable means for discovering claims of compliance and
- determining the current tracking status.
- </p>
- <p>
- Unfortunately, providing a dynamic indication of tracking compliance
- on every HTTP response is not feasible, since it would have the
- effect of disabling caching for the entire Web. Instead, this
- protocol defines a combination of response mechanisms that allow
- the information to be communicated without making every response
- dynamic.
+ This protocol has the dual goals of expressing the user's preference
+ regarding tracking and providing transparency by communicating
+ machine-readable claims that a server might wish to make regarding
+ its own tracking behavior. However, providing a dynamic tracking
+ status on every response would effectively disable caching for the
+ entire Web. Instead, this protocol defines a combination of response
+ mechanisms that allow this information to be communicated without
+ making every response dynamic.
</p>
<p>
This section explains how a user agent MAY discover an origin
@@ -541,7 +510,7 @@
status resources</a> for sites where
the tracking status might vary based on data within the request.
It also defines a <a>Tk</a> response header field that MAY be sent
- in any HTTP response, MUST be sent in responses to requests that
+ in any response, MUST be sent in responses to requests that
modify the tracking status, and MAY direct the
user to a request-specific tracking status resource applicable to
the current request.
@@ -556,32 +525,29 @@
<p>
A <dfn>tracking status value</dfn> (TSV) is a short notation for
- communicating how a designated resource conforms to the tracking
- protection protocol, as defined by this document and
- [[!TRACKING-COMPLIANCE]].
+ communicating the tracking behavior for data collected via a
+ <dfn>designated resource</dfn>.
+ </p>
+ <p>
For a site-wide tracking status resource, the designated resource
- to which the tracking status applies is any resource on the same
- origin server. For a <a>Tk</a> response header field, the
- corresponding request target is the designated resource and
- remains so for any subsequent request-specific tracking status
- resource referred to by that field.
+ is any resource on the same origin server.
+ For a <a>Tk</a> response header field, the target resource of the
+ corresponding request is the designated resource, and remains so
+ for any subsequent request-specific tracking status resource
+ referred to by the Tk field value.
</p>
<p>
The tracking status value is case sensitive, as defined formally
by the following ABNF.
</p>
<pre class="abnf">
-<dfn>TSV</dfn> = "1" ; "1" — first-party
- / "3" ; "3" — third-party
- / %x43 ; "C" - consent
- / %x44 ; "D" - disregarding
- / %x4E ; "N" - none
- / %x50 ; "P" - potential consent
+<dfn>TSV</dfn> = "0" ; "0" — not tracking
+ / "1" ; "1" — tracking
+ / "?" ; "?" - dynamic
+ / %x43 ; "C" - tracking with consent
+ / %x44 ; "D" - disregarding DNT
+ / %x50 ; "P" - tracking only if consented
/ %x55 ; "U" - updated
- / %x58 ; "X" - dynamic
- / ( "!" [testv] ) ; "!" - non-compliant
-
-<dfn>testv</dfn> = id-char
</pre>
<p class="issue" data-number="137" title="Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s)">
@@ -594,78 +560,55 @@
between a service provider acting for some other site and the same
service provider acting on one of its own sites.
</p>
+ <p class="issue" data-number="161" title="Do we need a tracking status value for partial compliance or rejecting DNT?">
+ <b>[PENDING REVIEW]</b> Not for partial compliance, since the
+ presence of a tracking status value no longer implies compliance.
+ See below for separate discussion of disregarding.
+ </p>
</section>
<section id='TSV-N' class="option">
- <h4>None (N)</h4>
+ <h4>Not Tracking (0)</h4>
<p>
- A tracking status value of <dfn>N</dfn> means the origin
- server claims that the designated resource does not perform
- tracking of any kind, not even for a <a>permitted use</a>,
- and does not make use of any data collected from tracking.
+ A tracking status value of <dfn>0</dfn> means the origin server
+ claims that data collected via the <a>designated resource</a> is
+ not used for tracking and will not be combined with other data in
+ a form that would enable tracking.
</p>
<p class="issue" data-number="119" title='Specify "absolutely not tracking"'>
- <b>[OPEN]</b> The <code><a>N</a></code> tracking status
- value corresponds to this notion of absolutely not tracking.
+ <b>[OPEN]</b> The <code><a>0</a></code> tracking status
+ value replaces the notion of absolutely not tracking.
</p>
</section>
<section id='TSV-1'>
- <h4>First Party (1)</h4>
- <p>
- A tracking status value of <dfn>1</dfn> means that the origin
- server claims that the designated resource is designed for use
- only within a first-party context and conforms to the requirements
- on a first party.
- If the designated resource is operated by an outsourced service
- provider, the service provider claims that it conforms to the
- requirements on a third party acting as a first party.
- </p>
- <p>
- For the site-wide tracking status and Tk header field, the tracking
- status values <code>1</code> and <code>3</code>
- indicate how the designated resource is designed to conform, not
- the nature of the request. Hence, if a user agent is making a
- request in what appears to be a third-party context and the
- tracking status value indicates that the designated resource is
- designed only for first-party conformance, then either the context
- has been misunderstood (both are actually the same party) or the
- resource has been referenced incorrectly.
- </p>
+ <h4>Tracking (1)</h4>
<p>
- For the request-specific tracking status resource, an indication
- of first or third party as the status value describes how the
- resource conformed to that specific request, and thus indicates
- the applicable set of requirements to which the origin server
- claims to conform.
+ A tracking status value of <dfn>1</dfn> means the origin server
+ might perform or enable tracking using data collected via the
+ <a>designated resource</a>. Information provided in the tracking
+ status representation might indicate whether such tracking is
+ limited to a set of commonly accepted uses or adheres to one or
+ more compliance regimes.
</p>
</section>
- <section id='TSV-3'>
- <h4>Third Party (3)</h4>
+ <section id='TSV-?'>
+ <h4>Dynamic (?)</h4>
<p>
- A tracking status value of <dfn>3</dfn> means that the origin
- server claims that the designated resource conforms to the
- requirements on a third party.
- </p>
- </section>
-
[623 lines skipped]
Received on Thursday, 28 November 2013 03:03:57 UTC