- From: CVS User rfieldin <cvsmail@w3.org>
- Date: Mon, 23 Mar 2015 18:40:25 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory gil:/tmp/cvs-serv12349
Modified Files:
tracking-dnt.html
Log Message:
(editorial) Remove tabs and make whitespace, indentation, capitalization, and header numbering consistent; update ref to TCS WD
--- /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 2015/03/20 13:46:12 1.281
+++ /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 2015/03/23 18:40:24 1.282
@@ -8,7 +8,7 @@
var respecConfig = {
specStatus: "ED",
shortName: "tracking-dnt",
- // publishDate: "2014-07-23",
+ // publishDate: "2015-03-23",
previousPublishDate: "2014-04-24",
previousMaturity: "LCWD",
edDraftURI: "http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html",
@@ -26,12 +26,12 @@
localBiblio: {
"TCS": {
"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",
+ "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" : "08 May 2014",
+ "date" : "25 November 2014",
"publisher" : "W3C"
},
"Orderly": {
@@ -47,8 +47,8 @@
<link rel="stylesheet" href="additional.css" type="text/css" media="screen" title="custom formatting for TPWG editors">
</head>
<body>
- <section id='abstract'>
- <p>
+ <section id='abstract'>
+ <p>
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
@@ -57,116 +57,115 @@
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>
-
- <section id='sotd'>
- <p>
- This document is an editors' straw man reflecting a snapshot of live
- discussions within the
- <a href="http://www.w3.org/2011/tracking-protection/">Tracking
- Protection Working Group</a>. It does not yet capture all of our work
- and does not constitute working group consensus.
- Text in option boxes (highlighted with light blue background color)
- present options that the group is currently considering, particularly
- where consensus is known to be lacking, and should be read as a set of
- proposals rather than as limitations on the potential outcome.
- An
- <a href="http://www.w3.org/2011/tracking-protection/track/issues/">issue tracking system</a>
- is available for recording
- <a href="http://www.w3.org/2011/tracking-protection/track/issues/raised">raised</a>,
- <a href="http://www.w3.org/2011/tracking-protection/track/issues/open">open</a>,
- <a href="http://www.w3.org/2011/tracking-protection/track/issues/pendingreview">pending review</a>,
- <a href="http://www.w3.org/2011/tracking-protection/track/issues/closed">closed</a>, and
- <a href="http://www.w3.org/2011/tracking-protection/track/issues/postponed">postponed</a>
- issues regarding this document.
- </p>
- <p>
- The following features are at risk and may be cut from the
- specification during its CR period if there are no (correct)
- implementations:
- </p>
- <ul>
- <li><a href="#dnt-extensions">DNT-extension</a></li>
- </ul>
- </section>
-
- <section>
- <h2>Introduction</h2>
+ </p>
+ </section>
- <p>
- The World Wide Web consists of billions of resources
- interconnected through the use of hypertext. Hypertext provides a
- simple, page-oriented view of the information provided by those
- resources, which can be traversed by selecting links, manipulating
- controls, and supplying data via forms and search dialogs.
- </p>
- <p>
- A Web page is often composed of many information sources beyond the
- initial resource request, including embedded references to
- stylesheets, inline images, javascript, and other elements that might
- be automatically requested as part of the rendering or behavioral
- processing defined for that page. The user's experience is seamless,
- even if the page has been composed from the results of many network
- interactions with multiple servers. From the user's perspective, they
- are simply visiting and interacting with a single Web site: all of the
- technical details and protocol mechanisms used to compose a page to
- represent that site are hidden behind the scenes.
- </p>
- <p>
- It has become common for Web site owners to collect data regarding
- the usage of their sites for a variety of purposes, including what
- led the user to visit their site (referrals), how effective the user
- experience is within the site (web analytics), and the nature of who
- is using their site (audience segmentation). In some cases, the data
- collected is used to dynamically adapt the content (personalization)
- or the advertising presented to the user (targeted advertising).
- Data collection often occurs through the insertion of embedded
- elements on each page, which connect the user's activity across
- multiple pages. A survey of these techniques and their
- privacy implications can be found in [[KnowPrivacy]].
- </p>
- <p>
- Users need a mechanism to express their own preferences regarding
- <a>tracking</a> that is both simple to configure and efficient when
- implemented. However, merely expressing a preference does not imply
- that all recipients will be able to comply. In some cases, a server
- might be dependent on some forms of tracking and is unwilling or
- unable to turn that off. In other cases, a server might perform only
- limited forms of tracking that would be acceptable to most users.
- Servers need mechanisms for communicating their tracking behavior and
- for storing a <a>user-granted exception</a> after the user has made an
- informed choice.
- </p>
- <p>
- This specification extends Hypertext Transfer Protocol (HTTP)
- semantics [[!RFC7231]] to communicate a user's tracking preference,
- if any, and an origin server's tracking behavior.
- The <a>DNT</a> request header field is defined for communicating the
- user's tracking preference for the request target. A well-known URI
- for a <a href="#status-resource">tracking status resource</a> and the
- <a>Tk</a> response header field are defined for communicating the
- server's tracking behavior. In addition, JavaScript APIs are defined
- for enabling scripts to determine DNT status and register a
- user-granted exception.
- </p>
- <p>
- This specification does not define requirements on what a recipient
- needs to do to comply with a user's expressed tracking preference,
- except for the means by which such compliance is communicated.
- Instead, the tracking status provides the ability to identify a set of
- compliance regimes to which the server claims to comply, with the
- assumption being that each regime defines its own requirements on
- compliant behavior. For example, [[TCS]] is a work-in-progress that
- intends to define such a compliance regime.
- </p>
- </section>
+ <section id='sotd'>
+ <p>
+ This document is an editors' straw man reflecting a snapshot of live
+ discussions within the
+ <a href="http://www.w3.org/2011/tracking-protection/">Tracking
+ Protection Working Group</a>. It does not yet capture all of our work
+ and does not constitute working group consensus.
+ Text in option boxes (highlighted with light blue background color)
+ present options that the group is currently considering, particularly
+ where consensus is known to be lacking, and should be read as a set of
+ proposals rather than as limitations on the potential outcome.
+ An
+ <a href="http://www.w3.org/2011/tracking-protection/track/issues/">issue tracking system</a>
+ is available for recording
+ <a href="http://www.w3.org/2011/tracking-protection/track/issues/raised">raised</a>,
+ <a href="http://www.w3.org/2011/tracking-protection/track/issues/open">open</a>,
+ <a href="http://www.w3.org/2011/tracking-protection/track/issues/pendingreview">pending review</a>,
+ <a href="http://www.w3.org/2011/tracking-protection/track/issues/closed">closed</a>, and
+ <a href="http://www.w3.org/2011/tracking-protection/track/issues/postponed">postponed</a>
+ issues regarding this document.
+ </p>
+ <p>
+ The following features are at risk and may be cut from the specification
+ during its CR period if there are no (correct) implementations:
+ </p>
+ <ul>
+ <li><a href="#dnt-extensions">DNT-extension</a></li>
+ </ul>
+ </section>
+
+ <section>
+ <h2>Introduction</h2>
+
+ <p>
+ The World Wide Web consists of billions of resources interconnected
+ through the use of hypertext. Hypertext provides a simple, page-oriented
+ view of the information provided by those resources, which can be
+ traversed by selecting links, manipulating controls, and supplying data
+ via forms and search dialogs.
+ </p>
+ <p>
+ A Web page is often composed of many information sources beyond the
+ initial resource request, including embedded references to stylesheets,
+ inline images, javascript, and other elements that might be
+ automatically requested as part of the rendering or behavioral
+ processing defined for that page. The user's experience is seamless,
+ even if the page has been composed from the results of many network
+ interactions with multiple servers. From the user's perspective, they
+ are simply visiting and interacting with a single Web site: all of the
+ technical details and protocol mechanisms used to compose a page to
+ represent that site are hidden behind the scenes.
+ </p>
+ <p>
+ It has become common for Web site owners to collect data regarding the
+ usage of their sites for a variety of purposes, including what led the
+ user to visit their site (referrals), how effective the user experience
+ is within the site (web analytics), and the nature of who is using their
+ site (audience segmentation). In some cases, the data collected is used
+ to dynamically adapt the content (personalization) or the advertising
+ presented to the user (targeted advertising). Data collection often
+ occurs through the insertion of embedded elements on each page, which
+ connect the user's activity across multiple pages. A survey of these
+ techniques and their privacy implications can be found in [[KnowPrivacy]].
+ </p>
+ <p>
+ Users need a mechanism to express their own preferences regarding
+ <a>tracking</a> that is both simple to configure and efficient when
+ implemented. However, merely expressing a preference does not imply that
+ all recipients will be able to comply. In some cases, a server might be
+ dependent on some forms of tracking and is unwilling or unable to turn
+ that off. In other cases, a server might perform only limited forms of
+ tracking that would be acceptable to most users. Servers need mechanisms
+ for communicating their tracking behavior and for storing a
+ <a>user-granted exception</a> after the user has made an informed
+ choice.
+ </p>
+ <p>
+ This specification extends Hypertext Transfer Protocol (HTTP) semantics
+ [[!RFC7231]] to communicate a user's tracking preference, if any, and an
+ origin server's tracking behavior. The <a>DNT</a> request header field
+ is defined for communicating the user's tracking preference for the
+ request target. A well-known URI for a
+ <a href="#status-resource">tracking status resource</a> and the
+ <a>Tk</a> response header field are defined for communicating the
+ server's tracking behavior. In addition, JavaScript APIs are defined for
+ enabling scripts to determine DNT status and register a user-granted
+ exception.
+ </p>
+ <p>
+ This specification does not define requirements on what a recipient
+ needs to do to comply with a user's expressed tracking preference,
+ except for the means by which such compliance is communicated. Instead,
+ the tracking status provides the ability to identify a set of compliance
+ regimes to which the server claims to comply, with the assumption being
+ that each regime defines its own requirements on compliant behavior.
+ For example, [[TCS]] is a work-in-progress that intends to define such a
+ compliance regime.
+ </p>
+ </section>
- <section id='terminology'>
- <h2>Terminology</h2>
+ <section id='terminology'>
+ <h2>Terminology</h2>
<section id='terminology.http'>
<h3>HTTP</h3>
+
<p>
The following terms are used as defined by HTTP/1.1 syntax [[!RFC7230]]
and semantics [[!RFC7231]]:
@@ -189,6 +188,7 @@
<section id='terminology.activity'>
<h3>Activity</h3>
+
<p>
<dfn>Tracking</dfn> is the collection of data regarding a particular
user's activity across multiple distinct contexts and the retention,
@@ -213,6 +213,7 @@
<section id='terminology.participants'>
<h3>Participants</h3>
+
<p>
A <dfn>user</dfn> is a natural person who is making, or has made,
use of the Web.
@@ -251,18 +252,18 @@
Access to Web resources often involves multiple parties that might
process the data received in a network interaction. For example,
domain name services, network access points, content distribution
- networks, load balancing services, security filters, cloud platforms,
- and software-as-a-service providers might be a party to a given
- network interaction because they are contracted by either the user or
- the resource owner to provide the mechanisms for communication.
- Likewise, additional parties might be engaged after a network
- interaction, such as when services or contractors are used to perform
- specialized data analysis or records retention.
+ networks, load balancing services, security filters, cloud
+ platforms, and software-as-a-service providers might be a party to a
+ given network interaction because they are contracted by either the
+ user or the resource owner to provide the mechanisms for
+ communication. Likewise, additional parties might be engaged after a
+ network interaction, such as when services or contractors are used
+ to perform specialized data analysis or records retention.
</p>
<p>
For the data received in a given network interaction, a
- <dfn>service provider</dfn> is considered to be the same party as its
- <dfn>contractee</dfn> if the service provider:
+ <dfn>service provider</dfn> is considered to be the same party as
+ its <dfn>contractee</dfn> if the service provider:
</p>
<ol>
<li>processes the data on behalf of the contractee;</li>
@@ -270,8 +271,8 @@
directed by the contractee;</li>
<li>has no independent right to use the data other than in a
<a>permanently de-identified</a> form (e.g., for monitoring
- service integrity, load balancing, capacity planning, or billing);
- and,</li>
+ service integrity, load balancing, capacity planning, or
+ billing); and,</li>
<li>has a contract in place with the contractee which is consistent
with the above limitations.</li>
</ol>
@@ -279,6 +280,7 @@
<section id='terminology.data'>
<h3>Data</h3>
+
<p>
A party <dfn>collects</dfn> data received in a network interaction
if that data remains within the party’s control after the network
@@ -293,8 +295,8 @@
that data to any other party.
</p>
<p>
- Data is <dfn>permanently de-identified</dfn> when there exists a high
- level of confidence that no human subject of the data can be
+ Data is <dfn>permanently de-identified</dfn> when there exists a
+ high level of confidence that no human subject of the data can be
identified, directly or indirectly (e.g., via association with an
identifier, user agent, or device), by that data alone or in
combination with other retained or available information.
@@ -303,6 +305,7 @@
<section id='terminology.preferences'>
<h3>Preferences</h3>
+
<p>
A <dfn>user-granted exception</dfn> is a specific tracking
preference, overriding a user's general tracking preference, that
@@ -310,171 +313,173 @@
<a href="#exceptions" class="sectionRef"></a>.
</p>
</section>
- </section>
+ </section>
- <section id='notational'>
- <h2>Notational Conventions</h2>
+ <section id='notational'>
+ <h2>Notational Conventions</h2>
- <section id='requirements'>
- <h3>Requirements</h3>
- <p>The key words <em title="must" class="rfc2119">must</em>,
- <em title="must not" class="rfc2119">must not</em>,
- <em title="required" class="rfc2119">required</em>,
- <em title="should" class="rfc2119">should</em>,
- <em title="should not" class="rfc2119">should not</em>,
- <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>
- </section>
+ <section id='requirements'>
+ <h3>Requirements</h3>
- <section id='notation'>
- <h3>Formal Syntax</h3>
- <p>
- This specification uses the Augmented Backus-Naur Form (ABNF)
- notation of [[!RFC5234]] to define network protocol syntax and
- WebIDL [[!WEBIDL]] to define scripting APIs.
- Conformance criteria and considerations regarding error handling are
- defined in Section 2.5 of [RFC7230].
- </p>
- </section>
+ <p>The key words <em title="must" class="rfc2119">must</em>,
+ <em title="must not" class="rfc2119">must not</em>,
+ <em title="required" class="rfc2119">required</em>,
+ <em title="should" class="rfc2119">should</em>,
+ <em title="should not" class="rfc2119">should not</em>,
+ <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>
</section>
- <section id='determining'>
- <h2>Determining User Preference</h2>
+ <section id='notation'>
+ <h3>Formal Syntax</h3>
<p>
- The goal of this protocol is to allow a user to express their
[3728 lines skipped]
Received on Monday, 23 March 2015 18:40:26 UTC