Network Working Group A. Cooper
Internet-Draft Center for Democracy & Technology
Intended status: Informational H. Tschofenig
Expires: September 8, 2011 Nokia Siemens Networks
March 7, 2011
Overview of Universal Opt-Out Mechanisms for Web Tracking
draft-cooper-web-tracking-opt-outs-00
Abstract
Web servers and the entities that operate them have long had the
ability to track user agents as they access resources hosted across
different web domains. Concern over the privacy implications of such
tracking has prompted recent work on a number of solutions that aim
to provide a universal opt-out mechanism for web tracking that can be
effectuated through a simple binary choice presented to users.
This document provides an overview of the following mechanisms:
permanent opt-out cookies, cookie blocking, domain blocking, a "Do
Not Track" (DNT) HTTP header, and a Do Not Track Document Object
Model (DOM) property. The aim of this document is to describe each
approach, the pros and cons of each, and areas where standardization
may be necessary should each approach be further pursued, without
making recommendations about which approach or approaches should be
adopted.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Cooper & Tschofenig Expires September 8, 2011 [Page 1]
Internet-Draft Tracking Opt-Outs Overview March 2011
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. History of Opt-Out Cookies . . . . . . . . . . . . . . . . 4
1.2. Drawbacks of Opt-Out Cookies . . . . . . . . . . . . . . . 4
1.3. New Tracking Opt-Out Mechanisms . . . . . . . . . . . . . 5
2. Terminology: First Party vs. Third Party . . . . . . . . . . . 6
3. Tracking Opt-Out Mechanisms . . . . . . . . . . . . . . . . . 8
3.1. Permanent Opt-Out Cookies . . . . . . . . . . . . . . . . 8
3.2. Cookie Blocking . . . . . . . . . . . . . . . . . . . . . 10
3.3. Domain Blocking . . . . . . . . . . . . . . . . . . . . . 10
3.4. Do Not Track HTTP Header . . . . . . . . . . . . . . . . . 12
3.5. Do Not Track DOM Property . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
7. Informational References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Cooper & Tschofenig Expires September 8, 2011 [Page 2]
Internet-Draft Tracking Opt-Outs Overview March 2011
1. Introduction
The Hypertext Transfer Protocol (HTTP) is a generic and stateless
application-level protocol for distributed collaborative hypermedia
information systems. The stateless nature of the HTTP protocol is a
useful property for scalability and for robustness. However, for
more complex web sites it is often important to carry state
information between different web pages and to offer reidentification
of previous visitors for usability reasons. This has lead web
application developers to invent mechanisms for maintaining state
information about end user interactions. In fact, one mechanism -
the cookie (originally specified in [RFC2109] and now being revised
by [I-D.ietf-httpstate-cookie]) - has been added to HTTP itself.
Since cookies come with limitations, such as the number of cookies
that are allowed to be stored per domain, the size of an individual
cookie, and the total number of cookies that can be stored, it is not
the only state management concept used by developers. Other
mechanisms include combinations of server-side databases, hidden form
fields, URL query parameters, extensions to the CGI model, storage
capabilities offered by additional plug-ins (such as Adobe Flash and
Microsoft Silverlight), HTML5 web storage, and special browser
extensions (such as Internet Explorer's userdata behavior).
State created by the web server allows the server to uniquely
identify individual user agents, providing a mechanism to correlate
information about the activity of a single user agent across requests
for different resources. Many of today's web sites cause user agents
to fetch resources from a large number of other sites which may also
make use of state management techniques.
State information, such as cookie state stored within the browser, is
not accessible to every site due to user agent security policies
(which may include the same-origin policy
[I-D.abarth-principles-of-origin] and its variations), but sharing of
information between web sites visited by a single user can take many
different forms. Data may be shared between two sites that both
cause requests to the same third site, by sites that share DNS CNAME
records or authoritative DNS servers, or between sites that share
identifying URLs or referer headers [Krishnamurthy06]
[Krishnamurthy07]. These techniques, together with uses of cookies,
Javascript, Flash, and other mechanisms for data aggregation
purposes, have become pervasive among popular web sites
[Krishnamurthy09], allowing users to be tracked in a multitude of
ways.
Concern over the privacy implications of this tracking has prompted
recent work on a number of different solutions that aim to provide a
universal opt-out mechanism for web tracking that can be effectuated
Cooper & Tschofenig Expires September 8, 2011 [Page 3]
Internet-Draft Tracking Opt-Outs Overview March 2011
through a simple binary choice presented to users. This document
provides an overview of several such mechanisms.
1.1. History of Opt-Out Cookies
Web tracking was first widely employed by "third-party" advertising
networks, which locate their advertising resources at their own
domains (not at the "first-party" domains to which user agents
typically issue requests at the direction of users). User agent
requests for top-level documents from many separate first-party
domains often generate requests for resources that are all located at
the same third-party ad network domain, providing the ad network with
the ability to build a profile of the first-party resources accessed
by the user agent. Ad networks then use these profiles to
individually tailor ads served to a particular user agent. This
practice is known as "behavioral advertising."
Concern over the privacy implications of the tracking involved in
behavioral advertising gave rise in 1999 to the Network Advertising
Initiative (NAI), a consortium of online advertising companies
[NAI-History]. Shortly after its formation, the NAI developed a set
of guidelines that its member companies were bound to follow. Among
these guidelines was a requirement that the ad companies provide web
users with the ability to opt out of ad targeting [NAI-Guidelines].
The primary mechanism adopted for effectuating the opt out was an
"opt-out cookie": an HTTP cookie that stores the user's preference to
be opted out of ad targeting. Under the guidelines, NAI members
could provide users with links to set their opt-out cookies from
their own web sites and from a central site [NAI-Registry]. A newer
central site now provides users with access to the opt-out cookies
for companies that are members of a number of other advertising trade
associations in addition to the NAI, all of which are operating under
the banner of the Digital Advertising Alliance (DAA) [DAA10].
1.2. Drawbacks of Opt-Out Cookies
Several drawbacks to the opt-out cookie approach have been identified
over time. Storing the user's preference in a cookie is problematic
because users are often encouraged to delete their cookies in order
to protect their privacy. If they follow this advice, they delete
their opt-out cookies as well, and ad targeting resumes.
Because HTTP cookies are typically only returned to the origin server
that set them [I-D.ietf-httpstate-cookie], using cookies to control
user preferences requires that users obtain individual opt-out
cookies for each tracking domain. With current upper estimates for
the number of tracking domains reaching over 300
Cooper & Tschofenig Expires September 8, 2011 [Page 4]
Internet-Draft Tracking Opt-Outs Overview March 2011
[PrivacyChoice-Tracker-Index], this creates a complex cookie
management task for users.
Not all of these tracking domains are used for behavioral
advertising. Tracking -- in the generic sense of correlating a
single user agent's requests across multiple domains -- is used for a
number of other purposes, including web analytics, web site
personalization, ad reporting (e.g., calculating the number of ad
views or clicks), market research, fraud detection, and federated
authentication. Like behavioral advertising, some of these services
(web analytics, ad reporting, some market research services) use
cookies as their primary means of identifying user agents and could
therefore make use of opt-out cookies to store user preferences. But
recent investigations have indicated that only about half of the 300
or so tracking domains offer opt-out cookies [Brock11]. Meanwhile,
the DAA site offers the opt-out cookies of only about 60 companies.
For some of the other tracking purposes, using an opt-out cookie
would make little sense. For example, a site or service that
requires users to authenticate to obtain access to a personal profile
might find it more reasonable to store the user's opt-out choice on a
back-end system as part of the user's profile. Since cookies were
designed to overcome the statelessness of web transactions, any site
or service that persists state about individual users in some non-
cookie-based storage can likely find a more streamlined way to store
individual opt-out preferences than by using opt-out cookies.
Opt-out cookies also do not control tracking that makes use of other
technologies. Flash cookies, HTML5 web storage, browser
fingerprinting, the CSS history leak, and a number of other non-HTTP-
cookie mechanisms can be used to track web activity across domains
[Kamkar10][EFF][Baron10].
1.3. New Tracking Opt-Out Mechanisms
For all of these reasons, a number of new solutions have been
proposed to improve upon the status quo for opting out of web
tracking. While these mechanisms differ in their implementations,
they share a similar goal: to provide a universal opt-out for web
tracking that can be effectuated through a simple binary choice
presented to users (this will be referred to hereafter as the "DNT
goal"). This document provides an overview of the following
mechanisms:
o Permanent opt-out cookies
o Cookie blocking
Cooper & Tschofenig Expires September 8, 2011 [Page 5]
Internet-Draft Tracking Opt-Outs Overview March 2011
o Domain blocking
o Do Not Track HTTP header
o Do Not Track Document Object Model (DOM) property
The aim is to generally describe each approach, the pros and cons of
each, and areas where standardization may be necessary should each
approach be further pursued. This document does not recommend any
particular solution or set of solutions. This is very much a first
draft; feedback and insights into the various approaches are most
welcome.
2. Terminology: First Party vs. Third Party
There are a number of web-related terms that have taken on special
meaning within discussions about web tracking. Some of these
meanings may differ from the common understanding of the same terms
in the IETF context.
In the context of web tracking, a "domain" usually refers to the
portion of a web resource's host name comprised of the second-level
domain and top-level domain. For example, the domain corresponding
to http://count.example.com/ would be example.com. The term
"subdomain" is often used to describe a fully qualified domain name
(FQDN). For example, the URI http://count.example.com/ contains the
subdomain count.example.com.
A "first-party domain" usually refers to the domain of a web site to
which a user agent directs an explicit request on behalf of a user.
A "third-party domain" usually refers to the domain of a web resource
that a user agent requests as a result of a first-party request. A
third-party resource is hosted at a different domain from the first-
party domain that triggers the third-party request. As an example,
if a user directs his user agent to http://www.foo.com/ and as a
result the user agent also makes a request to www.bar.com, foo.com is
the first-party domain and bar.com is the third-party domain.
This distinction between first-party and third-party domains is in
part a result of long-standing user agent practices for handling HTTP
cookies. Typically, HTTP cookies are returned only to the origin
server that set them [I-D.ietf-httpstate-cookie]. Cookies set from
first-party domains may not be read by third-party domains and vice
versa. In some cases, cookies set from first-party domains that
contain subdomains are accessible by all subdomains of the first-
party domain. The distinction between first-party domains and third-
party domains is reflected in browser-based cookie controls: major
Cooper & Tschofenig Expires September 8, 2011 [Page 6]
Internet-Draft Tracking Opt-Outs Overview March 2011
web browsers all offer distinct first-party cookie settings and
third-party cookie settings.
However, a user's perception or expectation of the difference between
a "first party" and a "third party" may not fall neatly within the
distinction between "first-party domain" and "third-party domain."
Consider Example Company, which hosts its web site at example.com and
contracts with an analytics service provider, Count Company. The
analytics service is architected such that it operates from
count.example.com, a subdomain. When a user visits www.example.com,
a request is triggered to count.example.com, and data about the
user's visit is returned to count.example.com to be processed by
Count Company. Although all of these exchanges would be between the
user agent and first-party domains, the user may only expect to be
sending data to Example Company (the "first party"), not to Count
Company (the "third party").
Conversely, consider that Example Company runs a social network,
Example Social, hosted at examplesocial.com, and a photo-sharing
service, Example Photos, hosted at examplephotos.com. Example Social
might have a feature that allows users to share their photos from
Example Photo on their profiles hosted at examplesocial.com. In this
case, a user agent that requests a resource hosted at
examplesocial.com would also automatically request and receive
content hosted at examplephotos.com. While user agents might
consider examplephotos.com to be a third-party domain, the user might
consider all the content they receive to be coming from a single
first party, Example Company.
It has been suggested that this distinction between first parties and
third parties from the user expectation perspective can be
approximated by distinguishing domains based on their Public Suffixes
[Mozilla] plus one additional domain label ("PS+1")
[I-D.mayer-do-not-track].
In the remainder of this document, "first-party domain" and "third-
party domain" will be used to describe the typical distinction used
by web browsers between the two types of cookies; the terms "first
party" and "third party" will be used when the user expectation
perspective is more appropriate.
A summary of the terminology used in the document (some of which is
drawn from [I-D.mayer-do-not-track]) is as follows:
o Domain: The portion of a web resource's host name comprised of the
second-level domain and top-level domain.
Cooper & Tschofenig Expires September 8, 2011 [Page 7]
Internet-Draft Tracking Opt-Outs Overview March 2011
o DNT goal: To provide a universal opt-out for web tracking that can
be effectuated through a simple binary choice presented to users.
o First party: A functional entity with which a user reasonably
expects to exchange data.
o First-party domain: The domain of a web site to which a user agent
directs an explicit request on behalf of a user.
o Third party: A functional entity that a user does not reasonably
expect to receive the user's data.
o Third-party domain: The domain of a web resource that a user agent
requests as a result of a first-party request.
3. Tracking Opt-Out Mechanisms
The mechanisms described in this section are at various stages of
development, deployment, and standardization. The mechanisms are not
necessarily mutually exclusive; it is possible that a combination of
approaches could be employed to fulfill different aspects of opt-out
functionality, although the mechanics of such combinations are out of
scope for this document. It is also possible that some of the
mechanisms or similar concepts could be adapted to address tracking
outside of the web context -- for example, within mobile applications
or email applications. These other contexts are likewise out of
scope.
Much of the privacy concern about web tracking has focused on
tracking conducted by third parties because it often occurs without
the knowledge of users and is performed by companies with which users
may have no relationship. However, tracking may also be performed by
first parties. For example, first parties may track users in order
to provide personalized or customized content, or they may share
information about user agent requests with third parties who then
aggregate that information across multiple first parties. While the
traditional opt-out cookie approach does not address first-party
tracking, some of the newer mechanisms could be implemented in a way
so as to address first-party tracking. A discussion of the extent to
which each of the mechanisms addresses first-party tracking is
included in the sections below.
3.1. Permanent Opt-Out Cookies
A number of web browser extentions exist to make opt-out cookies
permanent: Targeted Advertising Cookie Opt-Out (TACO) for Firefox and
Google Chrome [Abine11], Keep My Opt-Outs (KMOO) for Chrome
Cooper & Tschofenig Expires September 8, 2011 [Page 8]
Internet-Draft Tracking Opt-Outs Overview March 2011
[Google11], and Keep MORE Opt-Outs, developed by PrivacyChoice
[PrivacyChoice11]. These extensions first install the opt-out
cookies for a number of ad companies -- all NAI members for KMOO and
larger lists of companies for the other two extensions. If the user
already has uniquely identifying cookies for any domains on the list,
those cookies are deleted. Thereafter, the extensions wait for a
cookie change event and preserve the opt-out cookies even when a user
clears his or her cookies.
The main benefit of this approach is that it does not require any
changes on the server side. Servers used to track user agents can
continue to operate as they have since opt-out cookies were first
introduced. This approach can also apply to tracking conducted for
many different purposes or to tracking from first-party domains --
any domain that offers an opt-out cookie could be included in the
list of domains for which the browser extension installs an opt-out
cookie. Keep MORE Opt-Outs, for example, takes this approach.
While this approach overcomes one of the limitations of opt-out
cookies -- their lack of persistence -- it still requires managing
potentially hundreds of opt-out cookies and ensuring that the list of
precisely which opt-out cookies to retain remains up-to-date even as
entities that track reconfigure their own cookie-setting practices on
the server side. This may amount to a complex managerial task for
the browser extension developer. Furthermore, for all entities that
conduct tracking but do not offer an opt-out cookie -- of which there
are potentially hundreds -- this approach will not work for those
entities' domains.
Most opt-out cookies do not contain unique user agent identifiers, so
installing a domain's opt-out cookie and deleting other uniquely
identifying cookies from that domain will generally prevent that
domain from continuing to track the user agent via HTTP cookies
(while also providing a way for users to verify that they have been
opted out). However, in general it does not prevent tracking via
other means such as Flash cookies or HTML5 web storage.
No existing implementations of this approach exist natively in user
agents; they are all currently browser extensions that require user-
initiated installation. If this approach were to be pursued further,
there may be a need to specify a standard way of representing the
list of opt-out cookies that a particular user agent or extension
makes permanent and/or the rules for processing the list (similar to
what may be required to standardize block lists, see Section 3.3).
Cooper & Tschofenig Expires September 8, 2011 [Page 9]
Internet-Draft Tracking Opt-Outs Overview March 2011
3.2. Cookie Blocking
Since much web tracking has historically occurred via HTTP cookies,
it has been suggested that providing users with simple settings to
turn cookie blocking on and off may serve the purpose of a universal,
binary tracking opt-out choice. All of the major web browsers offer
blanket settings for blocking all third-party cookies. However,
current implementations differ in their functionality; for example,
in some browsers, blocking third-party cookies prevents third-party
cookies that the user had previously downloaded from being read,
whereas in other cases pre-existing third-party cookies can continue
to be read and the block merely prevents new third-party cookies from
being set on a going-forward basis. This kind of variation reflects
different evaluations of the trade-off between the benefits of more
comprehensive blocking and the potential for cookie blocking to alter
or break the functionality of certain web sites.
The main advantages of the cookie-blocking approach are that it
targets what is still the most common means of tracking (HTTP
cookies) and it is already built into the most widely used web
browsers. However, because of the variations across the browsers,
some implementations -- particularly those that continue to allow
some third-party cookie reading or setting even after users have
affirmatively chosen to block third-party cookies -- may not match
users' expectations of what a universal tracking opt-out solution
should accomplish.
On the other hand, complete third-party cookie blocking does have the
potential to inhibit the functionality of some web sites (including
functionality unrelated to tracking). Some sites may even prevent
users from accessing the sites unless they re-enable third-party
cookies. This kind of behavior serves as a disincentive to using
existing cookie-blocking settings as a means to achieve the DNT goal.
When it prevents uniquely identifying third-party cookies from being
read, cookie blocking can be an effective and user-verifiable tool
for opting users out of tracking of all kinds. In addition to third-
party cookie blocking, most browsers also provide a setting to block
all first-party cookies, but because use of this setting breaks
significant amounts of web functionality, it is not a reasonable
mechanism for opting out of tracking from first-party domains. Nor
does cookie blocking have any effect on tracking that occurs via
other means.
3.3. Domain Blocking
Domain blocking requires the user agent to maintain a list of domains
to block and to block requests that the user agent would otherwise
Cooper & Tschofenig Expires September 8, 2011 [Page 10]
Internet-Draft Tracking Opt-Outs Overview March 2011
make to domains on the list. If the list is comprised of domains
from which tracking occurs, domain blocking prevents tracking by
preventing the user agent from communicating with those domains.
Domain blocking has been used for years to block web content of many
different kinds, including advertising (see, for example, the AdBlock
Plus extension for Firefox and Chrome [AdBlock-Plus]). The Tracking
Protection feature in Microsoft Internet Explorer 9 makes use of
third-party domain blocking (among other functionality)
[Microsoft10]. Many implementations of domain blocking have the
ability to periodically update their block lists (by contacting some
authoritative source) to stay up-to-date with server reconfigurations
and other changes.
Although giving users a simple binary choice about blocking a list of
domains is likely sufficient to achieve the DNT goal, the domain
blocking approach can also include more granular options that give
users finer-grained control over their web communications. Existing
implementations allow blocking at the level of a subdomain, path or
file, for example. They also combine domain blocking with domain
whitelisting so that certain domains are kept affirmatively
reachable.
Domain blocking is a powerful solution because it entirely prevents
tracking from occuring via any mechanism that originates with a web
server request, including cookie setting, other HTTP-header-based
mechanisms, and the transmission of scripts, images or other files
that trigger tracking. Domain blocking is also verifiable in that
observing requests issued by the user agent will demonstrate that
domains on the list are not being accessed.
However, to an even greater extent than cookie blocking, domain
blocking may cause site functionality to break. For domains that
conduct tracking and serve content from the same domain, blocking
will prevent both the tracking and the content delivery, even if the
user desires to opt out of the tracking without losing access to the
content or some version of the content. Domain operators that want
to be able to continue serving content and tracking user agents in
the face of pervasive domain blocking would need to conduct these
activities from separate domains (as was envisioned in the original
proposal for behavioral advertising domain blocking [CDT07]), keeping
only the tracking domain on the block lists. In some cases this
change could require significant costs in terms of server
reconfiguration. Moreover, domain operators whose domains are placed
on block lists against their will could seek to avoid being blocked
by switching domains (possibly on a recurring basis to circumvent
list updates). And as with cookie blocking, first-party domains that
detect domain blocking may require users to turn domain blocking off
before providing access to first-party content.
Cooper & Tschofenig Expires September 8, 2011 [Page 11]
Internet-Draft Tracking Opt-Outs Overview March 2011
Domain blocking requires that the list of domains to block be kept
up-to-date, which may require some management overhead. Domain
blocking cannot be used to block first-party tracking since blocking
first-party domain requests would prevent users from accessing
content that they explicitly wished to access.
The IE 9 Tracking Protection feature allows for block lists to be
independently created according to a specified file format. The
format and the rules for processing block list entries have been
submitted to the W3C for potential standardization [Zeigler11].
AdBlock Plus has its own filter list format [AdBlock-Plus-Filters].
Ultimately, standardization of the block list format and processing
rules is likely to be required if the goal is for multiple user
agents to be able to use the same independently created block lists.
3.4. Do Not Track HTTP Header
The proposed Do Not Track HTTP header is a user agent feature that
appends a new header to HTTP requests that expresses the user's
preference not to be tracked. In existing header implementations,
the header value is binary: 1 means no tracking and 0 means tracking
is permissible. Users can control whether the header is sent through
a simple browser preference. A DNT header has been implemented in
the current Firefox beta [Stamm] and in a number of browser
extensions [Soghoian][Palant11][NoScript]. Depending on the user
agent's policy, the header could be appended to every web request, or
to a subset of requests (for example, only third-party domain
requests, or all requests aside from those for which the user has
explicitly chosen to permit tracking).
Unlike the mechanisms already discussed, the DNT header does not
provide a technical means of enforcing any sort of ban on tracking.
Cookies and other tracking mechanisms would still be operational.
Thus the presence of the header does not run the risk of directly
interfering with existing web site functionality (as cookie or domain
blocking might).
Rather, the header provides a statement of the user's preference to
the domains to which the user agent makes requests. This creates the
possibility for the header to provide much broader-based protection
against tracking than the other mechanisms if the majority of
tracking entities abide by it. Every tracking entity that receives
the header would be able to act on it, including first parties,
entities that use tracking for purposes other than behavioral
advertising, and entities that track users via mechanisms other than
HTTP cookies.
The lack of a technical enforcement mechanism creates a need to
Cooper & Tschofenig Expires September 8, 2011 [Page 12]
Internet-Draft Tracking Opt-Outs Overview March 2011
develop some common understanding of what "tracking" means, how
domain operators should behave when they receive the header, and to
whom the header applies. Should first parties that share tracking
data with third parties be required to abide by the header? Should
first parties and third parties be distinguished by domain name or by
user expectation? Should tracking for certain purposes (fraud
detection or ad reporting, for example) be permitted regardless of
whether the header is present? Should the header affect the extent
to which web request data is retained on the server side? There are
a number of efforts underway to try to develop some consensus about
the answers to these and other questions in a way that balances the
realities of web server operation, legitimate uses of web request
data, and users' desire for privacy protection
[Mayer][CDT11][Eckersley11]. One of these efforts is seeking to
define the semantics and intended usage of the header in the context
of its potential standardization at the IETF
[I-D.mayer-do-not-track]. How these questions are answered will
determine the extent to which server-side reconfiguration is
necessary for entities that wish to honor the header.
Until some sort of consensus is reached about the semantics and usage
of the header on the server side, the level of protection against
tracking that the header affords will remain uncertain. Even if a
common semantic were established, the header would still require
users to trust that their web request data, including unique
identifiers sent via cookies or other means, would not be used for
tracking whenever the header is present. This sort of guarantee may
require enforcement or intervention from governmental privacy
authorities in order to truly be effective.
As with cookie blocking, some sites that detect the header may
prevent users from accessing their content, or they may request that
users turn the header off before access is granted. If the header is
deployed without granular user control over the sites to which it is
sent, this kind of server-side reaction to the header could
incentivize users to simply turn the header off entirely, because
they would have no way to send the header to some sites but not
others. Regardless of whether controls exist or not, having
individual sites that ignore the header or that ask users to disable
it frustrates the DNT goal of having a universal, binary opt-out
mechanism.
For a DNT header to be interoperable across web sites and user
agents, it would need to be defined according to the syntax specified
in the HTTP protocol specification [RFC2616] and registered according
to the procedures in RFC 3864 [RFC3864]. This path is currently
being pursued in [I-D.mayer-do-not-track]. Standardization of the
header has also been proposed to the W3C [Zeigler11].
Cooper & Tschofenig Expires September 8, 2011 [Page 13]
Internet-Draft Tracking Opt-Outs Overview March 2011
3.5. Do Not Track DOM Property
In a similar vein to the DNT header, the Document Object Model (DOM)
could be extended to include a property that expresses the user's
preference with respect to tracking. Users could set the value of
the property through a simple browser preference, causing the
property to be set for all documents (or for documents from some
subset of domains, with exceptions specified by the user). Client-
side code could query the property before taking tracking-related
actions.
The DOM property has similar advantages and disadvantages as the
header. Its mere deployment need not interfere with any existing web
functionality. It has the potential to be accessed and respected by
first parties and trackers of all kinds, although its applicability
is limited to sites architected to have access to the DOM -- tracking
that occurs entirely on the server side will be unaffected by the
property. Responding to the presence of the property will require
some shared understanding of the property's semantics. Its presence
may lead sites to request that users allow tracking in order to
access the desired content.
One way in which the property differs from the header is that it may
reduce the number of server calls made on behalf of users who opt out
of tracking. This could be the case if detection of the property
causes client-side code not to make requests to tracking domains that
otherwise would have been made. This lack of requests issued on
behalf of users who have opted out could provide a limited means for
users to verify that their preference is being honored -- if users
who set the property to the "no tracking" setting observe fewer or
different server calls than users who allow tracking, this may
provide some proof that sites are honoring the property, although
this would likely need to be evaluated on a site-by-site basis since
sites may need to implement their responses to the property
differently.
As with the header, for the DOM property to be interoperable, its
syntax and semantics would need to be standardized. A DNT DOM
property has been proposed to the W3C for standardization [Zeigler11]
4. Security Considerations
This document describes various mechanisms that allow users to opt-
out of web tracking. Thus one way to frame the security goal of
these solutions is the prevention of information leakage to those
doing the tracking, particularly third parties. The adversary from a
user agent point of view can therefore be considered to be any third
Cooper & Tschofenig Expires September 8, 2011 [Page 14]
Internet-Draft Tracking Opt-Outs Overview March 2011
party that conducts tracking.
Because any information that is shared with a third party could
potentially be used to identify a user agent, altogether preventing
communication with third-party domains when a user contacts a first-
party domain is perhaps the most intuitive way to prevent information
leakage to third parties. For example, a user agent might be
configured to serve content only from example.com when a user enters
http://www.example.com in the browser address bar. However, this
approach of preventing all third-party communications is unrealistic
since today's web sites often combine content aggregated from many
other sites. Hence the task of preventing third-party tracking is
more complicated. To address this complexity, the mechanisms
discussed in this draft are either more subtle or more granular (or
both) than all-out blocking of third parties, and they all face a
number of security challenges.
Regardless of whether any opt-out mechanism is used, first parties
always have the ability to convey information related to tracking to
third parties through an out-of-band or back-end channel. Since user
agents cannot observe these exchanges, there is little they can do to
prevent them.
The same origin policy treats subdomains as belonging to the first-
party domain. However, a first party can configure its DNS servers
in a way that a DNS CNAME alias points to a server belonging to
another organization. With appropriate cookie settings by the first
party, it is possible for the third party to obtain access to all
cookies. Permanent opt-out cookies, cookie blocking, and domain
blocking are not able to prevent this data sharing if they are
configured to respect the usual same origin policy. A DNT header or
DOM property may prevent this sharing if the first party respects the
user's preference as signaled by the header or property.
All techniques that block direct communication to specific third
party sites (via a block list mechanism) suffer from the generic
limitations of blacklisting mechanisms. Third parties that want to
avoid being blocked will regularly change their domains, attempt to
require users to exert additional effort in order to manage
blacklists, or relay communication through intermediaries to
obfuscate the identification of their domains. To emphasize the
negative impact on user experiences that blacklisting can have, some
third parties may bundle extra functionality onto the same (blocked)
domain, rendering it inaccessible to those using block lists.
The online management of block lists raises questions about who
provides the lists, how easy they are for users to download or
reconfigure, which list is used by default, what security mechanisms
Cooper & Tschofenig Expires September 8, 2011 [Page 15]
Internet-Draft Tracking Opt-Outs Overview March 2011
control the manipulation of the lists, and what conflict resolution
mechanism is offered when black and white lists are combined. The
answers to these questions depend heavily on the technology chosen
for managing the lists. Failing to secure the lists against
manipulation could allow information to be leaked to third parties
against the user's wishes.
Mechanisms that convey user preferences in a header or as a DOM
property will require the receiving party to adhere to the
instructions. As with the block listing mechanisms, implementation
details pertaining to the default settings in browsers, the ease of
changing the settings, and whether the settings can be manipulated
will affect the security of the settings themselves.
Some web proxies, gateways, and other intermediaries are known to
strip certain HTTP headers (the Referer header, for example) or only
allow a strict set of HTTP headers to pass through. While third-
party companies are unlikely to have the incentive to cooperate with
these intermediaries for the explicit purpose of removing or
modifying the DNT header, such removal would result in the user's
preference not being expressed to receiving servers. Scripts could
be used to modify or disable the DNT header or DOM property within
the browser to achieve the same effect, but these are fairly easy to
detect and therefore unlikely to be abused by third parties that want
to conduct tracking against the user's will. Given that third
parties can simply ignore the user's preference if they want to
conduct tracking under the DNT header or DOM property scenarios,
these attacks are unlikely to be used.
5. IANA Considerations
This document makes no requests of IANA.
6. Acknowledgments
The authors would like to thank Michael Hanson for inspiring the work
on this draft and Justin Brookman, Sue Glueck, and Erica Newland for
their reviews.
7. Informational References
[Abine11] Abine, "Targeted Advertising Cookie Opt-Out (TACO)", http
s://addons.mozilla.org/en-US/firefox/addon/
targeted-advertising-cookie-op/, February 2011.
Cooper & Tschofenig Expires September 8, 2011 [Page 16]
Internet-Draft Tracking Opt-Outs Overview March 2011
[AdBlock-Plus]
AdBlock Plus, "AdBlock Plus", http://adblockplus.org/en/.
[AdBlock-Plus-Filters]
AdBlock Plus, "Writing Adblock Plus filters",
http://adblockplus.org/en/filters.
[Baron10] Baron, D., "Preventing attacks on a user's history through
CSS :visited selectors",
http://dbaron.org/mozilla/visited-privacy, April 2010.
[Brock11] Brock, J., "Keep MORE Opt Outs", http://
blog.privacychoice.org/2011/01/31/keep-more-opt-outs/,
January 2011.
[CDT07] Cooper, A., "Dispelling "Do Not Track" Myths", http://
www.cdt.org/blogs/alissa-cooper/
dispelling-do-not-track-myths, October 2007.
[CDT11] Center for Democracy & Technology, "What Does "Do Not
Track" Mean? A Scoping Proposal from the Center for
Democracy & Technology",
http://cdt.org/files/pdfs/CDT-DNT-Report.pdf.
[DAA10] Digital Advertising Alliance, "Opt Out from Online
Behavioral Advertising",
http://www.aboutads.info/choices/, 2010.
[EFF] Electronic Frontier Foundation, "Panopticlick",
http://panopticlick.eff.org/.
[Eckersley11]
Eckersley, P., "What Does the "Track" in "Do Not Track"
Mean?", https://www.eff.org/deeplinks/2011/02/
what-does-track-do-not-track-mean.
[Google11]
Google, "Keep My Opt-Outs", https://chrome.google.com/
webstore/detail/hhnjdplhmcnkiecampfdgfjilccfpfoe,
January 2011.
[I-D.abarth-principles-of-origin]
Barth, A., "Principles of the Same-Origin Policy",
draft-abarth-principles-of-origin-00 (work in progress),
February 2011.
[I-D.ietf-httpstate-cookie]
Barth, A., "HTTP State Management Mechanism",
Cooper & Tschofenig Expires September 8, 2011 [Page 17]
Internet-Draft Tracking Opt-Outs Overview March 2011
draft-ietf-httpstate-cookie-23 (work in progress),
March 2011.
[I-D.mayer-do-not-track]
Mayer, J., Narayanan, A., and S. Stamm, "Do Not Track: A
Universal Third-Party Web Tracking Opt Out,
draft-mayer-do-not-track-00 (work in progress)",
March 2011.
[Kamkar10]
Kamkar, S., "Evercookie", http://samy.pl/evercookie/,
September 2010.
[Krishnamurthy06]
Krishnamurthy, B. and C. Wills, "Generating a privacy
footprint on the Internet. In Proceedings of the ACM
SIGCOMM Internet Measurement Conference, pages 65-70, Rio
de Janeiro, Brazil, October 2006",
http://www.cs.wpi.edu/~cew/papers/imc06.pdf.
[Krishnamurthy07]
Krishnamurthy, B., Malandrino, D., and C. Wills,
"Measuring privacy loss and the impact of privacy
protection in web browsing. In Proceedings of the
Symposium on Usable Privacy and Security, pages 52-63,
Pittsburgh, PA USA, July 2007. ACM International
Conference Proceedings Series.",
http://www.cs.wpi.edu/~cew/papers/soups07.pdf.
[Krishnamurthy09]
Krishnamurthy, B. and C. Wills, "Privacy diffusion on the
web: A longitudinal perspective. In Proceedings of the
World Wide Web Conference, pages 541-550, Madrid, Spain,
April 2009", http://www.cs.wpi.edu/~cew/papers/www09.pdf.
[Mayer] Mayer, J. and A. Narayanan, "Do Not Track: Universal Web
Tracking Opt-Out", http://donottrack.us/.
[Microsoft10]
Microsoft, "IE9 and Privacy: Introducing Tracking
Protection", http://blogs.msdn.com/b/ie/archive/2010/12/
07/
ie9-and-privacy-introducing-tracking-protection-v8.aspx,
December 2010.
[Mozilla] Mozilla Foundation, "Public Suffix List",
http://publicsuffix.org/.
Cooper & Tschofenig Expires September 8, 2011 [Page 18]
Internet-Draft Tracking Opt-Outs Overview March 2011
[NAI-Guidelines]
Network Advertising Initiative, "Network Advertising
Initiative Self-Regulatory Principles for Online
Preference Marketing by Network Advertisers",
http://www.ftc.gov/os/2000/07/NAI%207-10%20Final.pdf,
July 2000.
[NAI-History]
Network Advertising Initiative, "Network Advertising
Initiative History",
http://www.networkadvertising.org/about/history.asp.
[NAI-Registry]
Network Advertising Initiative, "Network Advertising
Initiative Opt-Out Registry",
http://www.networkadvertising.org/managing/opt_out.asp.
[NoScript]
Maone, G., "X-Do-Not-Track? DNT, c'est plus facile...", h
ttp://hackademix.net/2011/01/28/
x-do-not-track-dnt-cest-plus-facile/.
[Palant11]
Palant, W., "Adblock Plus and (a little) more: Updated
roadmap (Adblock Plus 1.3.5)", https://adblockplus.org/
blog/updated-roadmap-adblock-plus-135, February 2011.
[PrivacyChoice-Tracker-Index]
PrivacyChoice, "PrivacyChoice Tracker Index",
http://www.privacychoice.org/companies/all.
[PrivacyChoice11]
PrivacyChoice, "Keep MORE Opt-Outs", https://
chrome.google.com/extensions/detail/
eoibfeagdaaoimfpfalgbmmegagdconp, January 2011.
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
[Soghoian]
Cooper & Tschofenig Expires September 8, 2011 [Page 19]
Internet-Draft Tracking Opt-Outs Overview March 2011
Soghoian, C. and S. Stamm, "Universal Behavioral
Advertising Opt-Out", https://addons.mozilla.org/en-US/
firefox/addon/universal-behavioral-advertisi/.
[Stamm] Stamm, S., "Implement do-not-track HTTP header to express
user intent to halt tracking across site",
http://hg.mozilla.org/mozilla-central/rev/6963333a74d1.
[Zeigler11]
Zeigler, A., Bateman, A., and E. Graff, "Web Tracking
Protection: W3C Member Submission 24 February 2011",
http://www.w3.org/Submission/web-tracking-protection/,
February 2011.
Authors' Addresses
Alissa Cooper
Center for Democracy & Technology
1634 Eye St. NW, Suite 1100
Washington, DC 20006
USA
Email: acooper@cdt.org
Hannes Tschofenig
Nokia Siemens Networks
Finland
Email: hannes.tschofenig@nsn.com
Cooper & Tschofenig Expires September 8, 2011 [Page 20]