- From: CVS User dsinger2 <cvsmail@w3.org>
- Date: Fri, 07 Dec 2012 00:25:16 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory gil:/tmp/cvs-serv32415
Added Files:
tracking-dnt-20121206.html
Log Message:
snapshot copy before the UA-UI-free exception check-in
--- /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt-20121206.html 2012/12/07 00:25:16 NONE
+++ /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt-20121206.html 2012/12/07 00:25:16 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: "2012-03-13",
previousPublishDate: "2012-03-13",
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/",
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 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
site-specific exceptions to DNT as desired.
</p>
</section>
<section id='sotd'>
<p>
This document is an editors' strawman 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.
For example, we have issues that are [PENDING REVIEW] with complete
text proposals that have not yet made it into this draft.
Text in blue boxes presents multiple options the group is considering.
Options included in this draft should not be read as limitations on
the potential outcome, but rather simply as possible options that are
currently under consideration by the working group.
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 (WWW, or Web) consists of millions of sites
interconnected through the use of hypertext. Hypertext provides a
simple, page-oriented view of a wide variety of information that
can be traversed by selecting links, manipulating controls, and
supplying data via forms and search dialogs. A Web page is usually
composed of many different 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.
</p>
<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
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.
</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 can occur both at the first-party site and via
third-party providers through the insertion of tracking
elements on each page. A survey of these techniques and their
privacy implications can be found in [[KnowPrivacy]].
</p>
<p>
People have the right to know how data about them will be collected
and how it will be used. Empowered with that knowledge, individuals
can decide whether to allow their online activities to be tracked and
data about them to be collected. Many Internet companies use data
gathered about people's online activities to personalize content and
target advertising based on their perceived interests. While some
people appreciate this personalization of content and ads in certain
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.
</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.
</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>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
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">
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'>
<h3>Notational Conventions</h3>
<section id='requirements'>
<h4>Requirements</h4>
<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'>
<h4>Formal Syntax</h4>
<p>
This specification uses Augmented Backus-Naur Form [[!ABNF]]
to define network protocol syntax and WebIDL [[!WEBIDL]] for
defining scripting APIs.
</p>
</section>
<section id='terminology'>
<h4>Terminology</h4>
<p>
This specification uses the term <dfn>user agent</dfn> to refer to
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.
</p>
<p>
The term <dfn>user-granted exception</dfn> is used when the user has
permitted tracking by a given third party, usually in the form of a
site-specific exception.
</p>
<p>
A companion document, [[!TRACKING-COMPLIANCE]], defines many of the
terms used here, notably 'party', 'first party', and 'third party'.
</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
each service to either adjust their behavior to meet the user's
expectations or reach a separate agreement with the user to satisfy
all parties.
</p>
<p>
Key to that notion of expression is that it MUST reflect the user's
preference, not the choice of some vendor, institution, or
network-imposed mechanism outside the user's control. 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>unset</code> or
<code>DNT:1</code>.
A user agent MAY offer a third alternative choice: <code>DNT:0</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 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>.
Likewise, a user agent extension or add-on MUST NOT alter the tracking
preference unless the act of installing and enabling that extension or
add-on is an explicit choice by the user for that tracking preference.
</p>
<p>
We do not specify how 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>.
For example, a user might select a check-box in their user agent's
configuration, install an extension or add-on 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>).
The 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>
<p>
Although 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, the user is at least able to choose whether to
make use of those user agents. In contrast, 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.
Implementations of HTTP that are not under control of the user
MUST NOT generate or modify a tracking preference.
</p>
</section>
<section id='expressing'>
<h2>Expressing a Tracking Preference</h2>
<section id='expression-format'>
<h3>Expression Format</h3>
<p>
When a user has <a>enabled</a> a tracking preference, that
preference needs to be expressed to all mechanisms that might perform
or initiate tracking by third parties, including sites that the user
agent communicates with via HTTP, scripts that can extend behavior on
pages, and plug-ins or extensions that might be installed and
activated for various media types.
</p>
<p>
When <a>enabled</a>, a tracking preference is expressed as either:
<table class="simple">
<tr><th>DNT</th>
<th>meaning</th>
</tr>
<tr><td>1</td>
<td>This user prefers not to be tracked on the target site.</td>
</tr>
<tr><td>0</td>
<td>This user prefers to allow tracking on the target site.</td>
</tr>
</table>
</p>
<p>
A user agent MUST NOT send a tracking preference expression if
a tracking preference is <a>not enabled</a>. This means that no
expression is sent for each of the following cases:
<ul>
<li>the user agent does not implement this protocol;</li>
<li>the user has not yet made a choice for a specific preference;
or,</li>
<li>the user has chosen not to transmit a preference.</li>
</ul>
</p>
<p>
In the absence of regulatory, legal, or other requirements,
servers MAY interpret the lack of an expressed tracking preference
as they find most appropriate for the given user, particularly when
considered in light of the user's privacy expectations and cultural
circumstances. Likewise, servers might make use of other preference
information outside the scope of this protocol, such as site-specific
user preferences or third-party registration services, to inform or
adjust their behavior when no explicit preference is expressed via
this protocol.
</p>
</section>
<section id='dnt-header-field'>
<h3>DNT Header Field for HTTP Requests</h3>
<p>
The <dfn>DNT</dfn> header field is hereby defined as the means for
expressing a user's tracking preference via HTTP [[!HTTP11]].
</p>
<pre class="abnf">
<dfn>DNT-field-name</dfn> = "DNT" ; case-insensitive
<dfn>DNT-field-value</dfn> = ( "0" / "1" ) *DNT-extension ; case-sensitive
<dfn>DNT-extension</dfn> = %x21 / %x23-2B / %x2D-5B / %x5D-7E
; excludes CTL, SP, DQUOTE, comma, backslash
</pre>
<p>
A user agent MUST send the <dfn>DNT</dfn> header field on all HTTP
requests if (and only if) a tracking preference is
<a>enabled</a>.
A user agent MUST NOT send the <a>DNT</a> header field if a
tracking preference is <a>not enabled</a>.
</p>
<p>
The DNT field-value sent by a user agent MUST begin with the
numeric character "1" (%x31) if a tracking preference is
<a>enabled</a>, the preference is for no tracking, and
there is not a site-specific exception for the origin server
targeted by this request.
</p>
<p>
The DNT field-value sent by a user agent MUST begin with the
numeric character "0" (%x30) if a tracking preference is
<a>enabled</a> and the preference is to allow tracking in general
or by specific exception for the origin server targeted by this
request.
</p>
<pre class="example">
GET /something/here HTTP/1.1
Host: example.com
DNT: 1
</pre>
<p>
An HTTP intermediary MUST NOT add, delete, or modify the DNT header
field in requests forwarded through that intermediary unless that
intermediary has been specifically installed or configured to do so
by the user making the requests. For example, an Internet Service
Provider MUST NOT inject <q>DNT: 1</q> on behalf of all of their
users who have not expressed a preference.
</p>
<p>
The remainder of the DNT field-value after the initial character is
reserved for future extensions. User agents that do not implement
such extensions MUST NOT send DNT-extension characters in the DNT
field-value. Servers that do not implement such extensions SHOULD
ignore anything beyond the first character.
</p>
<p>
DNT extensions are to be interpreted as modifiers to the
main preference expressed by the first digit, such that the main
preference will be obeyed if the recipient does not understand the
extension. Hence, a DNT-field-value of "1xyz" can be thought of
as <q>do not track, but if you understand the
refinements defined by x, y, or z, then adjust my preferences
according to those refinements.</q>
DNT extensions can only be transmitted when a tracking
preference is <a>enabled</a>.
[1555 lines skipped]
Received on Friday, 7 December 2012 00:25:19 UTC