- From: CVS User ninja <cvsmail@w3.org>
- Date: Mon, 14 Apr 2014 12:15:27 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory gil:/tmp/cvs-serv9692/drafts
Added Files:
tracking-dnt-last-call.html
Log Message:
Upload of TPE snapshot for last call consensus
--- /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt-last-call.html 2014/04/14 12:15:27 NONE
+++ /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt-last-call.html 2014/04/14 12:15:27 1.1
<!DOCTYPE html>
<html lang="en" dir="ltr">
<head>
<title>Tracking Preference Expression (DNT)</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'>
<script src='http://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script>
<script class='remove'>
var respecConfig = {
specStatus: "ED",
shortName: "tracking-dnt",
// publishDate: "2014-03-13",
previousPublishDate: "2014-01-28",
previousMaturity: "WD",
edDraftURI: "http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html",
editors: [
{ name: "Roy T. Fielding", url: "http://roy.gbiv.com/",
company: "Adobe", companyURL: "http://www.adobe.com/" },
{ name: "David Singer",
company: "Apple", companyURL: "http://www.apple.com/" }
],
wg: "Tracking Protection Working Group",
wgURI: "http://www.w3.org/2011/tracking-protection/",
wgPublicList: "public-tracking",
wgPatentURI: "http://www.w3.org/2004/01/pp-impl/49311/status",
issueBase: "http://www.w3.org/2011/tracking-protection/track/issues/",
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",
"title" : "Tracking Compliance and Scope",
"date" : "08 April 2014",
"publisher" : "W3C"
},
"HTTP" : {
"title" : "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
"authors": ["Roy T. Fielding", "Julian Reschke"],
"status" : "Internet-Draft",
"date" : "6 February 2014",
"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" : "6 February 2014",
"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" : "6 February 2014",
"publisher" : "IETF",
"href" : "http://datatracker.ietf.org/doc/draft-ietf-httpbis-p6-cache/"
},
"RFC7159" : {
"title" : "The JavaScript Object Notation (JSON) Data Interchange Format",
"authors": ["Tim Bray, Ed."],
"status" : "Internet RFC 7159",
"date" : "March 2014",
"publisher" : "IETF",
"href" : "http://www.rfc-editor.org/rfc/rfc7159.txt"
}
},
noIDLSectionTitle: true
};
</script>
<link rel="stylesheet" href="additional.css" type="text/css" media="screen" title="custom formatting for TPWG editors">
</head>
<body>
<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
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>
<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>
</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
tracking 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 user-granted exceptions after the user has made an
informed choice.
</p>
<p>
This specification defines Hypertext Transfer Protocol [[!HTTP]]
elements for communicating the user's tracking preference (if any)
and communicating the server's tracking behavior (if any).
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
<a>user-granted exception</a>.
</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>
<p>
<dfn>Tracking</dfn> is the collection of data regarding a particular
user's activity across multiple distinct contexts and the retention,
use, or sharing of data derived from that activity outside the
context in which it occurred.
A <dfn>context</dfn> is a set of resources that are controlled by
the same party or jointly controlled by a set of parties.
</p>
<p>
A <dfn>user</dfn> is a natural person who is making, or has made,
use of the Web.
</p>
<p>
A <dfn>user agent</dfn> is any of the various client programs
capable of initiating HTTP requests [[!HTTP]], including (but not
limited to) browsers, spiders (web-based robots), command-line
tools, custom applications, and mobile apps.
</p>
<p>
A <dfn>network interaction</dfn> is a single HTTP request and its
corresponding response(s): zero or more interim (1xx) responses and
a single final (2xx-5xx) response.
</p>
<p>
A <dfn>user action</dfn> is a deliberate action by the user, via
configuration, invocation, or selection, to initiate a network
interaction. Selection of a link, submission of a form, and
reloading a page are examples of user actions.
<dfn>User activity</dfn> is any set of such user actions.
</p>
<p>
A <dfn>party</dfn> is a natural person, a legal entity, or a set of
legal entities that share common owner(s), common controller(s), and
a group identity that is easily discoverable by a user. Common
branding or providing a list of affiliates that is available via a
link from a resource where a party describes DNT practices are
examples of ways to provide this discoverability.
</p>
<p>
With respect to a given user action, a <dfn>first party</dfn>
is a party with which the user intends to interact, via one or more
network interactions, as a result of making that action. Merely
hovering over, muting, pausing, or closing a given piece of content
does not constitute a user's intent to interact with another party.
</p>
<p>
In some cases, a resource on the Web will be jointly controlled by
two or more distinct parties. Each of those parties is considered a
first party if a user would reasonably expect to communicate with
all of them when accessing that resource. For example, prominent
co-branding on the resource might lead a user to expect that
multiple parties are responsible for the content or functionality.
</p>
<p>
For any data collected as a result of one or more network
interactions resulting from a user's action,
a <dfn>third party</dfn> is any party other than that user, a first
party for that user action, or a service provider acting on behalf
of either that user or that first party.
</p>
<p>
A party <dfn>collects</dfn> data received in a network interaction
if that data remains within the party’s control after the network
interaction is complete.
</p>
<p>
A party <dfn>uses</dfn> data if the party processes the data for any
purpose other than storage or merely forwarding it to another party.
</p>
<p>
A party <dfn>shares</dfn> data if it transfers or provides a copy of
that data to any other party.
</p>
<p>
A <dfn>user-granted exception</dfn> is a specific tracking
preference, overriding a user's general tracking preference, that
has been obtained and recorded using the mechanisms defined in
<a href="#exceptions" class="sectionRef"></a>.
</p>
</section>
<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='notation'>
<h3>Formal Syntax</h3>
<p>
This specification uses Augmented Backus-Naur Form [[!ABNF]]
to define network protocol syntax and WebIDL [[!WEBIDL]] for
defining scripting APIs.
</p>
</section>
</section>
<section id='determining'>
<h2>Determining User Preference</h2>
<p>
The goal of this protocol is to allow a user to express their
personal preference regarding tracking to each server and
web application that they communicate with via HTTP, thereby allowing
recipients of that preference to adjust tracking behavior accordingly
or to reach a separate agreement with the user that satisfies all
parties.
</p>
<p>
Key to that notion of expression is that the signal sent MUST reflect
the user's preference, not the choice of some vendor, institution,
site, or network-imposed mechanism outside the user's control;
this applies equally to both the general preference and exceptions.
The basic principle is that a tracking preference expression is only
transmitted when it reflects a deliberate choice by the user. In the
absence of user choice, there is no tracking preference expressed.
</p>
<p>
A user agent MUST offer users a minimum of two alternative choices
for a <q>Do Not Track</q> preference: <code><dfn>unset</dfn></code> or
<code><dfn>DNT:1</dfn></code>.
A user agent MAY offer a third alternative choice: <code><dfn>DNT:0</dfn></code>.
</p>
<p>
If the user's choice is <code>DNT:1</code> or <code>DNT:0</code>, the
tracking preference is <dfn>enabled</dfn>; otherwise, the
tracking preference is <dfn>not enabled</dfn>.
</p>
<p>
A user agent MUST have a default tracking preference of
<code>unset</code> (not enabled) unless a specific tracking preference
is implied by the user's decision to use that agent. For example, use
of a general-purpose browser would not imply a tracking preference
when invoked normally as <q>SuperFred</q>, but might imply a
preference if invoked as <q>SuperDoNotTrack</q> or
<q>UltraPrivacyFred</q>.
</p>
<p>
Implementations of HTTP that are not under control of the user
MUST NOT add, delete, or modify a tracking preference.
Some controlled network environments, such as public access
terminals or managed corporate intranets, might impose restrictions
on the use or configuration of installed user agents, such that a
user might only have access to user agents with a predetermined
preference enabled. However, if a user brings their
own Web-enabled device to a library or cafe with wireless Internet
access, the expectation will be that their chosen user agent and
personal preferences regarding Web site behavior will not be
altered by the network environment (aside from blanket limitations
on what resources can or cannot be accessed through that network).
</p>
<p>
An HTTP intermediary MUST NOT add, delete, or modify a tracking
preference expression in a request forwarded through that intermediary
unless the intermediary has been specifically installed or configured
to do so by the user making the request. For example, an Internet
Service Provider MUST NOT inject <code>DNT:1</code> on behalf of all
users who have not expressed a preference.
</p>
<p>
User agents often include user-installable <dfn>extensions</dfn>, also
known as <dfn>add-ons</dfn> or <dfn>plug-ins</dfn>, that are
capable of modifying configurations and making network requests. From
the user's perspective, these extensions are considered part of the
user agent and ought to respect the user's configuration of a tracking
preference. The user agent as a whole is responsible for ensuring
conformance with this protocol, to the extent possible, which means
the user agent core and each extension are jointly responsible for
conformance. However, there is no single standard for extension
interfaces. A user agent that permits such extensions SHOULD provide
an appropriate mechanism for extensions to determine the user's
tracking preference.
</p>
<p>
A user agent extension MUST NOT alter the tracking preference
expression or its associated configuration unless the act of
installing and enabling that extension is an explicit choice by the
user for that tracking preference, or the extension itself complies
with all of the requirements this protocol places on a user agent.
</p>
<p>
Likewise, software outside of the user agent might filter network
traffic or cause a user agent's configuration to be changed.
Software that alters a user agent configuration MUST adhere to the
above requirements on a user agent extension. Software that filters
network traffic MUST adhere to the above requirements on an HTTP
intermediary.
</p>
<p>
Aside from the above requirements, we do not specify how the tracking
preference choices are offered to the user or how the preference is
enabled: each implementation is responsible for determining the user
experience by which a tracking preference is <a>enabled</a>.
</p>
<p>
For example, a user might select a check-box in their user agent's
configuration, install an extension that is specifically
designed to add a tracking preference expression,
or make a choice for privacy that then implicitly includes a
tracking preference (e.g., <q>Privacy settings: high</q>).
A user agent might ask the user for their preference during startup,
perhaps on first use or after an update adds the tracking protection
feature. Likewise, a user might install or configure a proxy to add
the expression to their own outgoing requests.
</p>
[1829 lines skipped]
Received on Monday, 14 April 2014 12:15:34 UTC