Copyright © 2011 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark and document use rules apply.
Trackingresponse header field for third-party resources that engage in cross-site tracking, and a mechanism for allowing the user toselectively opt-back-in for specific sites that require such data collection.approve site-specific exemptions to DNT as desired.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is an early rough draft of an initial straw-man document for the working group to consider at its next F2F meeting in Santa Clara. It does not represent working group consensus by any stretch of the imagination, though an attempt has been made to highlight areas where issues have been identified and present multiple alternatives if they have been discussed.
This document was published by the Tracking Protection Working Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to public-tracking@w3.org ( subscribe , archives ). All feedback is welcome.
Publication as a Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
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.
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 first-party 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.
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 analytics providers through the insertion of tracking elements on each page.
Advertising revenue is the single largest source of funding on the Web. Since advertisers desire an audience that is receptive to whatever they happen to be advertising, a significant premium is assigned to sites that can demonstrate a favorable target audience, and even more so for sites that are able to identify their audience dynamically and adjust the advertising displayed to be specific to the interests of that user. In an attempt to better understand or predict those interests, some advertising mechanisms follow a user's actions over time, collect data on the observed behavior, and use that data for targeting future advertisements: a practice commonly referred to as online behavioral advertising (OBA).
Like analytics data collection, Web sites often contract with third-party advertising networks for the tasks of selecting, delivering, and measuring the advertising shown on their sites, while advertisers often contract with third-party verification companies to provide independent accounting of ad impressions and fraud detection.
There are numerous techniques for integrating advertising networks into a website, though most involve some form of embedded resource request to a site controlled by the advertising network. Since the advertising networks are supplying ads for multiple sites, they are capable of monitoring how often a given ad is displayed to that same user agent across their entire network (frequency capping). Naturally, advertisers consider frequency capping to be a desirable feature, and thus it is common for advertisers to contractually limit advertising campaigns to a maximum impression count per user. As a result, advertising networks track users from site to site even when OBA is not in use.
In
many
cases,
Web
users
welcome
the
use
of
data
collection
for
personalization
and
targeted
advertising,
since
it
can
allow
a
site
to
tailor
the
user
experience
to
their
specific
desires,
reduce
ads
that
are
irrelevant
or
repetitive,
and
avoid
the
imposition
of
more
direct
revenue
in
the
form
of
subscription-only
services.
In
other
cases,
personalization
and
targeting
can
be
perceived
as
creepy
,
intrusive,
and
sometimes
simply
incorrect.
In
particular,
targeting
and
personalization
can
evoke
strong
negative
feelings
when
data
collected
at
a
trusted
site
is
used,
without
the
user's
consent,
for
targeting
ads
on
some
other
site
with
which
they
have
no
personal
trust
relationship.
When
cross-site
tracking
or
cross-site
sharing
of
data
collection
does
not
match
the
user's
expectations
regarding
privacy,
the
result
can
be
a
very
angry
customer.
None
of
the
participants
in
this
Web
of
customization
and
targeted
advertising
want
to
offend
the
user.
For
advertisers,
it
is
counterproductive.
For
Web
site
owners,
it
drives
away
their
audience
and
income.
For
advertising
networks,
it
leads
to
blocking
and
lost
advertisers.
Therefore,
we
need
a
mechanism
for
the
user
to
express
their
own
preference
regarding
cross-site
tracking
that
is
both
simple
to
configure
and
efficient
when
implemented.
Likewise,
since
some
Web
sites
may
be
dependent
on
the
revenue
obtained
from
targeted
advertising
and
unwilling
(or
unable)
to
permit
use
of
their
content
without
cross-site
data
collection,
we
need
a
mechanism
for
sites
to
alert
the
user
to
those
requirements
and
allow
the
user
to
opt-back-in
configure
an
exemption
to
tracking
DNT
for
specific
sites.
This specification defines the HTTP request header field DNT for expressing a tracking preference on the Web, a well-known location (URI) for providing a machine-readable site-wide policy regarding DNT compliance, and the HTTP response header field Tracking for third-party resources engaged in dynamic tracking behavior to communicate their compliance or non-compliance with the user's expressed preference.
A
companion
document,
Tracking
Compliance
and
Scope
,
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.
The key words must , must not , required , should , should not , recommended , may , and optional in this specification are to be interpreted as described in [ RFC2119 ].
This specification uses Augmented Backus-Naur Form [ ABNF ] to define network protocol syntax and WebIDL [ WEBIDL ] for defining scripting APIs.
HTTP
[
HTTP11
]
This
specification
uses
the
term
user
agent
to
refer
to
any
of
the
various
client
programs
capable
of
initiating
HTTP
requests,
including
browsers,
spiders
(web-based
robots),
command-line
tools,
native
applications,
and
mobile
apps.
Although
the
protocol
defined
by
this
specification
is
applicable
to
all
forms
of
user
agent,
the
compliance
requirements
are
specifically
concerned
with
the
privacy
expectations
of
a
human
user
and
the
tracking
of
their
browsing
history
over
time.
Hence,
user
agents
that
do
not
have
some
form
of
"browsing"
nature
or
do
not
communicate
with
more
than
one
site
are
not
expected
to
comply
with
this
protocol.
apps
[
HTTP11
].
ISSUE-13
:
What
are
the
requirements
for
DNT
on
apps/native
software
in
addition
to
browsers?
[PENDING
REVIEW]
The
above
paragraph
aims
at
resolving
this
issue.
The
goal
of
this
protocol
is
to
allow
a
user
to
express
their
personal
preference
regarding
cross-site
tracking
to
each
server
and
web
application
that
they
communicate
with
via
HTTP,
thereby
allowing
each
server
to
either
adjust
their
behavior
to
meet
the
user's
expectations
or
reach
a
separate
agreement
with
the
user
to
satisfy
both
parties.
Key
to
that
notion
of
expression
is
that
it
must
reflect
the
user's
choice,
preference,
not
the
choice
preference
of
some
institutional
or
network-imposed
mechanism
outside
the
user's
control.
The
remainder
of
this
specification
defines
the
protocol
in
terms
of
whether
the
user
has
DNT
is
enabled
or
not
enabled
DNT.
.
We
do
not
specify
how
that
preference
is
configured:
the
user
agent
is
responsible
for
determining
the
user
experience
by
which
the
user's
tracking
this
preference
is
set.
For
example,
a
user
might
configure
their
own
user
agent
to
tell
servers
do
not
track
me
cross-site
,
install
a
plug-in
or
extension
that
is
specifically
designed
to
add
that
expression,
or
make
a
choice
for
privacy
that
then
implicitly
includes
a
tracking
preference
(e.g.,
Privacy
settings:
high
).
For
each
of
these
cases,
we
say
that
the
user
has
DNT
is
enabled
DNT.
.
ISSUE-4
:
What
is
the
default
for
DNT
in
client
configuration
(opt-in
or
opt-out)?
[PENDING
REVIEW]
Proposed
text
above.
When a user has configured 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.
The
DNT
header
field
is
hereby
defined
as
the
means
for
expressing
a
user's
tracking
preference
via
HTTP
[
HTTP11
].
A
user
agent
must
send
the
DNT
header
field
on
all
HTTP
requests
if
(and
only
if)
its
user
has
DNT
is
enabled
DNT.
.
A
user
agent
must
not
send
the
DNT
header
field
if
its
user
has
DNT
is
not
enabled
DNT.
.
DNT-field-name = "DNT" ; case-insensitive DNT-field-value = ( "0" / "1" ) *DNT-extension ; case-sensitiveDNT-extension = %x21-7E ; any visible ASCIIDNT-extension = %x21-2B / %x2D-7E ; visible ASCII except ","
The
DNT
field-value
sent
by
a
user
agent
must
begin
with
the
character
"1"
(%x31)
if
the
user
has
DNT
is
enabled
DNT
and
has
there
is
not,
to
the
user
agent's
knowledge,
granted
an
a
specific
exception
to
for
the
origin
server
targeted
by
this
request.
If
the
user
has
DNT
is
enabled
DNT
and
has
specifically
opted
into
tracking
there
is
a
specific
exception
for
the
target
origin
server
via
some
mechanism
understood
by
the
user
agent,
then
the
DNT
field-value
sent
by
a
user
agent
must
begin
with
the
character
"0"
(%x30).
ISSUE-78
:
What
is
the
difference
between
absence
of
DNT
header
and
DNT
=
0?
[PENDING
REVIEW]
Proposed
text
above
defines
that
a
"0"
may
only
be
sent
when
DNT
is
enabled
and
some
mechanism
known
to
the
user
agent
has
specifically
made
an
exception
for
this
origin
server.
Note
that
we
have
not
defined
such
a
mechanism
(and
probably
won't
do
so).
If
DNT
is
disabled
or
not
implemented,
no
DNT
header
field
is
sent.
GET /something/here HTTP/1.1 Host: example.com DNT: 1
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
DNT:
1
on
behalf
of
all
of
their
users
who
have
not
selected
a
choice.
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.
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
DNT
is
enabled,
but
if
you
understand
the
refinements
defined
by
x,
y,
or
z,
then
adjust
my
preferences
according
to
those
refinements.
Extensions
can
only
transmitted
if
the
user
has
DNT
is
enabled
DNT.
.
The
extension
syntax
excludes
the
comma
(",")
character
in
order
to
to
differentiate
valid
field
values
from
an
invalid
occurrence
of
multiple
DNT
header
fields
that
have
been
combined
as
a
single
comma-separated
list
by
a
generic
HTTP
parser.
Designers
of
future
extensions
should
note
that,
once
enabled
by
the
user,
if
enabled,
DNT
is
sent
on
every
request
and
is
thus
in
the
critical
path
for
a
server
attempting
to
read
and
act
on
every
request.
Use
as
few
extension
characters
as
possible.
ISSUE-82
:
Should
the
DNT
header
be
extensible
with
additional
parameters?
[PENDING
REVIEW]
The
above
paragraphs
allow
for
an
extension
string.
At
this
point,
no
extensions
have
been
defined.
The
NavigatorDoNotTrack
interface
provides
a
means
for
the
user's
cross-site
tracking
preference
to
be
expressed
to
web
applications
running
within
a
page
rendered
by
the
user
agent.
Navigator
implements
NavigatorDoNotTrack
;
Navigator
interface
[
NAVIGATOR
]
(e.g.,
the
window.navigator
object)
must
also
implement
the
NavigatorDoNotTrack
interface.
An
instance
of
NavigatorDoNotTrack
is
obtained
by
using
binding-specific
casting
methods
on
an
instance
of
Navigator
.
ISSUE-84
:
Do
we
need
a
JavaScript
API
/
DOM
property
for
client-side
js
access
to
Do
Not
Track
status?
[PENDING
REVIEW]
We
believe
that
we
need
such
an
API.
This
section
proposes
one.
TBD.
User
agents
often
include
user-installable
component
parts,
commonly
known
as
plug-ins
or
browser
extensions
,
that
are
capable
of
making
their
own
network
requests.
From
the
user's
perspective,
these
components
are
considered
part
of
the
user
agent
and
thus
ought
to
respect
the
user's
configuration
of
a
tracking
preference.
However,
plug-ins
do
not
normally
have
read
access
to
the
browser
configuration.
Therefore,
we
will
define
here
various
mechanisms
for
communicating
the
DNT
preference
via
common
plug-in
APIs.
Tracking Compliance and Scope, defines how service providers are expected to comply when they receive an expression of the user's tracking preference via any of the mechanisms described in section 4. Expressing a Tracking Preference .
If no DNT preference is received, it may indicate either that the user has chosen to allow cross-site tracking or that their user agent does not support this protocol for expressing DNT (e.g., user agents deployed prior to this protocol's existence). In the absence of regulatory, legal, or other requirements, servers are free to interpret the lack of a DNT header as they find most appropriate for the given user, particularly when considered in light of the user's privacy expectations and cultural circumstances.
This
section
defines
how
a
server
communicates
its
compliance
with
tracking
preferences,
including
whether
it
will
honor
the
user's
preference,
require
some
form
of
opt-back-in,
site-specific
exemption,
or
believes
indicate
that
it
already
has
the
user's
permission
via
some
other
agreement
(e.g.,
a
subscription
or
account
agreement).
Optionally,
links
can
be
provided
to
human-readable
information
regarding
the
site's
tracking
policies
or
where
to
go
to
opt-in,
opt-out,
or
edit
their
personal
information.
The following goals have been identified as reasons for having a response from the server:
The following criteria have been identified as constraints on the response design:
There have been many suggestions, but not much consensus, on how servers ought to respond when DNT is enabled. The various suggestions can be roughly categorized as follows:
and
also
some
combinations
of
the
above.
For
example,
we
might
define
that
compliant
servers
provide
a
machine-readable
site-wide
policy
that
indicates
how
they
honor
DNT,
what
sites
are
considered
the
same
brand,
and
links
to
resources
for
opt-back-in
and
providing
site-specific
exemptions
to
DNT
or
editing
collected
tracking
data,
and
data.
We
could
then
only
provide
limit
use
of
a
dynamic
tracking
response
header
field
response
to
only
those
dynamic
responses
for
third-party
resources
that
engage
in
tracking.
ISSUE-81
:
Do
we
need
a
response
at
all
from
server?
[PENDING
REVIEW]
Yes:
The
users
expect
to
be
able
to
see
whether
a
DNT
header
is
accepted,
rejected,
or
sent
into
the
void.
ISSUE-79 : Should a server respond if a user sent DNT:0?
ISSUE-51 : Should 1st party have any response to DNT signal
This can be defined as either a well-known location, as defined by RFC5785, or as a Link header field sent in response to any request (regardless of DNT).
ISSUE-47 : Should the response from the server point to a URI of a policy (or an existing protocol) rather than a single bit in the protocol?
ISSUE-80 : Instead of responding with a Link: header URI, does it make sense to use a well-known location for this policy?
ISSUE-87 : Should there be an option for the server to respond with "I don't know what my policy is"
ISSUE-61 : A site could publish a list of the other domains that are associated with them
i am neutral) and dynamic headers when
I am a tracking element and I accept your choice to not be tracked
I see that you say DNT, but i am tracking you for the following reasons.
ISSUE-76 : Should a server echo the DNT header to confirm receipt?
ISSUE-48 : Response from the server could both acknowledge receipt of a value and (separately) whether the server will honor it
ISSUE-90 : Interaction of DNT with caching and intermediaries
An
HTTP
error
response
status
code
might
be
useful
for
indicating
that
the
site
refuses
service
unless
the
user
either
logs
into
a
subscription
account
or
agrees
to
opt-back-in
an
exemption
to
tracking
DNT
for
this
site
and
its
contracted
third-party
sites.
ISSUE-43 : Sites should be able to let the user know their options when they arrive with Do Not Track
ISSUE-27 : How should the "opt back in" mechanism be designed?
ISSUE-46 : Enable users to do more granular blocking based on whether the site responds honoring Do Not Track
It
would
annoy
users
of
DNT
if
they
are
presented
with
an
opt-back-in
exemption
dialog
each
time
they
visit
a
site.
This specification consists of input from many discussions within and around the W3C Tracking Protection Working Group, along with written contributions from Roy T. Fielding (Adobe), Tom Lowenthal (Mozilla), Aleecia M. McDonald (Mozilla), Matthias Schunter (IBM), and Shane Wiley (Yahoo!).
The
DNT
header
field
is
based
on
the
original
Do
Not
Track
submission
by
Jonathan Mayer
(Stanford),
Arvind Narayanan
(Stanford),
and
Sid Stamm
(Mozilla).
The
DOM
API
for
NavigatorDoNotTrack
is
based
on
the
Web
Tracking
Protection
submission
by
Andy Zeigler,
Adrian Bateman,
and
Eliot Graff
(Microsoft).
Many
thanks
to
Robin Berjon
for
ReSpec.js.
ISSUE-2
:
What
is
the
meaning
of
DNT
(Do
Not
Track)
header?
[CLOSED]
"Does
the
presence
of
a
DNT
header
field
on
requests
always
indicate
an
explicit
choice".
ISSUE-50 : Are DNT headers sent to first parties? Yes
ISSUE-70 : Does a past HTTP request with DNT set affect future HTTP requests? No
ISSUE-40
:
Enable
Do
Not
Track
just
for
a
session,
rather
than
being
stored
[CLOSED]
Resolved
in
DNT
Call
2011-10-26:
The
user
agents
are
free
to
send
different
DNT
values
for
different
sessions.
We
agreed
that
this
is
a
user-interface
issue
and
out
of
scope
on
its
own.
ISSUE-68
:
Should
there
be
functionality
for
syncing
preferences
about
tracking
across
different
browsers?
[CLOSED]
Resolved
in
DNT
Call
2011-10-26:
The
user
agents
may
or
may
not
sync.
However,
this
is
out
of
scope
for
this
spec.
ISSUE-42 : Feedback to the user from the browser when Do Not Track is turned on
ISSUE-44
:
Ability
to
measure/detect
who
is
honoring
Do
Not
Track
at
a
technical
level
[POSTPONED]
The
info
at
the
well-known
URI
declares
whether
a
server
promises
to
follow
DNT.
Whether
it
actually
does
(or
just
pretends
to
do
so)
is
hard
to
determine
and
should
be
addressed
later.
ISSUE-64
:
How
does
site
preference
management
work
with
DNT
[POSTPONED]
To
what
extent
cookies
can
be
used
for
preference
management
(such
as
storing
a
language
preference)
will
be
resolved
later.
No informative references.