Network Working Group J. Mayer
Internet-Draft A. Narayanan
Intended status: Standards Track Stanford University
Expires: September 8, 2011 S. Stamm
Mozilla
March 7, 2011
Do Not Track: A Universal Third-Party Web Tracking Opt Out
draft-mayer-do-not-track-00
Abstract
This document defines the syntax and semantics of Do Not Track, an
HTTP header-based mechanism that enables users to express preferences
about third-party web tracking. It also provides a standard for how
web services should comply with such user preferences.
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
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
Mayer, et al. Expires September 8, 2011 [Page 1]
Internet-Draft Do Not Track March 2011
described in the Simplified BSD License.
Table of Contents
1. Recognition . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5
6. User Agent Requirements . . . . . . . . . . . . . . . . . . . 5
6.1. OPTIONAL Support . . . . . . . . . . . . . . . . . . . . . 5
6.2. User Interface RECOMMENDED . . . . . . . . . . . . . . . . 6
6.3. Default . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Intermediary Requirements . . . . . . . . . . . . . . . . . . 6
8. Server Requirements . . . . . . . . . . . . . . . . . . . . . 6
8.1. Opt Out . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.2. Opt In . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.3. Header Not Present . . . . . . . . . . . . . . . . . . . . 6
8.4. Response Header RECOMMENDED . . . . . . . . . . . . . . . 6
9. Server Policy . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Definitions of "First Party" and "Third Party" . . . . . . 7
9.2. Definition of "Tracking" . . . . . . . . . . . . . . . . . 8
9.3. Exceptions . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Implementation Considerations . . . . . . . . . . . . . . . . 8
10.1. Selective Opt Out and Opt In RECOMMENDED . . . . . . . . . 8
10.2. Verification . . . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 9
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
14.1. Normative References . . . . . . . . . . . . . . . . . . . 9
14.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Mayer, et al. Expires September 8, 2011 [Page 2]
Internet-Draft Do Not Track March 2011
1. Recognition
The Do Not Track effort is much broader than this standards document,
and we recognize the following individuals without whom Do Not Track
would not be possible. For a detailed history of Do Not Track, see
[HistoryOfDNT]. We particularly laud the efforts of Christopher
Soghoian, whose tireless advocacy led Do Not Track from a technical
prototype to a leading privacy proposal.
1.1. Contributors
Alissa Cooper
Center for Democracy and Technology
Christopher Soghoian
Indiana University
Ashkan Soltani
Harlan Yu
Princeton University
1.2. Acknowledgements
Peter Eckersley
Electronic Frontier Foundation
Alexander Fowler
Mozilla
John Mitchell
Stanford University
Lee Tien
Electronic Frontier Foundation
2. Introduction
The content of a website is increasingly sourced from numerous
entities. This development has given many companies the ability to
track users across millions of sites. A number of services now exist
Mayer, et al. Expires September 8, 2011 [Page 3]
Internet-Draft Do Not Track March 2011
solely to track users, often via invisible embedded content. Users
widely perceive such third-party tracking as an invasion of privacy
(see [WebsNewGoldMine] and [Turow09]).
The explosion of stateful (see [Evercookie], [Aggarwal10], and
[McKinley08]) and stateless (see [Eckersley10] and [Mayer09])
techniques for tracking users, accompanied by the proliferation of
third-party tracking (see [Krishnamurthy10]), prohibit a purely
technical means of preventing tracking. Do Not Track is instead a
means of allowing users to express their preferences about tracking,
including to opt out of tracking some or all of the time.
A preference signaling mechanism can, of course, be ignored by bad
actors. But the most pervasive third-party trackers are law-abiding
commercial enterprises (see [Krishnamurthy10]). This standard
intends to aid these fair players by allowing them to honor a user's
preferences.
3. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234].
The terms user agent, server, proxy, header, request, and response
have the same meaning as in the HTTP/1.1 specification ([RFC2616]).
"Explicit user consent" means a user is likely to understand and
accept the choice she makes. Agreement to a terms of service or
privacy policy does not, in general, constitute explicit user
consent.
A "functional entity" is a commercial, nonprofit, or government
organization, a subsidiary or unit of such an organization, or a
person.
"THIRD-PARTY TRACKING" is shorthand for activities covered by
Section 9.1 and Section 9.2, and not excepted by Section 9.3.
A "public suffix" is a domain name under which users can register
domain names. A list is maintained at [PublicSuffix]. This document
uses public suffixes instead of top-level domains (see [RFC0920])
because they more accurately reflect organizational boundaries.
Mayer, et al. Expires September 8, 2011 [Page 4]
Internet-Draft Do Not Track March 2011
"Protocol logs" means logs for all network protocols that arise from
an HTTP request and response.
4. Overview
This document is organized into two parts. The first part details
the technical implementation of Do Not Track: the header syntax
(Section 5), user agent requirements (Section 6), intermediary
requirements (Section 7), and server requirements (Section 8). The
second part provides the policy a server implementing Do Not Track
must observe (Section 9).
4.1. Example
In the status quo: A user navigates a sequence of popular websites,
many of which incorporate content from a major advertising network.
In addition to delivering advertisements, the advertising network
assigns a unique cookie to the user agent and compiles observations
of the user's browsing habits.
With Do Not Track: A user enables Do Not Track in her web browser.
She navigates a sequence of popular websites, many of which
incorporate content from a major advertising network. The
advertising network delivers advertisements, but refrains from THIRD-
PARTY TRACKING of the user.
5. Header Syntax
The Do Not Track HTTP header, "DNT", must take one of two values: "1"
("opt out") or "0" ("opt in"). All other values are reserved.
DNT = "DNT" ":" BIT
For clarity this document refers to an opt-out header as OPT-OUT, an
opt-in header as OPT-IN, and the absence of a header as NO-EXPRESSED-
PREFERENCE.
6. User Agent Requirements
6.1. OPTIONAL Support
A user agent MAY include a Do Not Track header in any HTTP request.
Mayer, et al. Expires September 8, 2011 [Page 5]
Internet-Draft Do Not Track March 2011
6.2. User Interface RECOMMENDED
A user agent that implements Do Not Track SHOULD provide a user
interface for modifying preferences. The user interface design is
left to the user agent.
6.3. Default
A user agent MAY adopt NO-EXPRESSED-PREFERENCE or OPT-OUT by default.
It MUST NOT transmit OPT-IN without explicit user consent.
7. Intermediary Requirements
A proxy or other intermediary MUST NOT add, remove, or modify a Do
Not Track header without explicit user consent.
8. Server Requirements
8.1. Opt Out
In processing a request that includes an OPT-OUT header, a server
MUST NOT perform THIRD-PARTY TRACKING. The server MUST instruct the
user agent to delete any data previously stored for THIRD-PARTY
TRACKING.
8.2. Opt In
In processing a request that includes an OPT-IN header, a server MAY
perform THIRD-PARTY TRACKING.
8.3. Header Not Present
In processing a NO-EXPRESSED-PREFERENCE request, a server MAY perform
THIRD-PARTY TRACKING. The functional entity responsible for the
server MUST NOT draw any inferences about a user's preferences from
the absence of an OPT-OUT or OPT-IN header.
8.4. Response Header RECOMMENDED
In responding to a request that includes a Do Not Track header, a
third-party server that complies with Do Not Track SHOULD echo the
request header. For example:
GET /thirdpartycontent.html HTTP/1.1
Host: thirdparty.example.com
Mayer, et al. Expires September 8, 2011 [Page 6]
Internet-Draft Do Not Track March 2011
DNT: 1
HTTP/1.1 200 OK
Date: Mon, 7 March 2011 01:23:45 GMT
Server: Apache/2.2.17 (Unix)
Content-Length: 123
Connection: close
Content-Type: text/html; charset=UTF-8
DNT: 1
This feature is intended to aid in the decentralized collection of
statistics about the Do Not Track mechanism, including adoption rates
and intermediary operations. It is also intended to clearly identify
whether a request was processed in compliance with Do Not Track.
9. Server Policy
This section specifies the requirements for server compliance with a
Do Not Track OPT-OUT: A server acting in a third-party capacity (see
Section 9.1) MUST NOT track (see Section 9.2) a user or user agent
unless subject to an exception (see Section 9.3).
9.1. Definitions of "First Party" and "Third Party"
A first party is a functional entity with which the user reasonably
expects to exchange data. In most cases the functional entity
responsible for the web page a user has navigated to is the sole
first party.
A third party is a functional entity with which the user does not
reasonably expect to share data. In general advertising networks,
analytics services, and social plug-in providers are third parties.
To a first approximation, a functional entity is a third party if it
differs from the current page in:
1. Public suffix plus one domain name (PS+1), or
2. PS+1 authoritative name servers, or
3. PS+1 of CNAME records.
We emphasize that this rule is only an approximation. Many first
parties span several domain names, and many third parties are located
at a subdomain of a first party.
In practice a third party usually interacts with a user agent via
content embedded on a first-party webpage. A third party could also
receive data from a first party.
Mayer, et al. Expires September 8, 2011 [Page 7]
Internet-Draft Do Not Track March 2011
9.2. Definition of "Tracking"
Tracking includes collection, retention, and use of all data related
to the request and response.
9.3. Exceptions
As a general guideline, exceptions to Do Not Track are warranted when
commercial interests substantially outweigh privacy and verification
interests. The following activities are excepted:
1. Tracking of users who have explicitly consented to tracking, such
as by enabling a checkbox in a preferences menu on the first-
party website of the tracking service.
2. Data obtained by a third party exclusively on behalf of and for
the use of a first party.
3. Data that is, with high confidence, not linkable to a specific
user or user agent. This exception includes statistical
aggregates of protocol logs, such as pageview statistics, so long
as the aggregator takes reasonable steps to ensure the data does
not reveal information about individual users, user agents,
devices, or log records. It also includes highly non-unique data
stored in the user agent, such as cookies used for advertising
frequency capping or sequencing. This exception does not include
anonymized data, which recent work has shown to be often re-
identifiable (see [Narayanan09] and [Narayanan08]).
4. Protocol logs, not aggregated across first parties, and subject
to a two week retention period.
5. Protocol logs used solely for advertising fraud detection, and
subject to a one month retention period.
6. Protocol logs used solely for security purposes such as intrusion
detection and forensics, and subject to a six month retention
period.
7. Protocol logs used solely for financial fraud detection, and
subject to a six month retention period.
To ensure data allowed for only specific uses is adequately
protected, functional entities SHOULD implement strong internal
controls.
10. Implementation Considerations
10.1. Selective Opt Out and Opt In RECOMMENDED
A user agent implementing Do Not Track SHOULD allow a user to
selectively opt out of or opt into tracking on specific first-party
websites, by specific third parties, or by specific third parties on
Mayer, et al. Expires September 8, 2011 [Page 8]
Internet-Draft Do Not Track March 2011
specific first-party websites. Definition and implementation of
selective opt out and opt in is outside the scope of this document.
10.2. Verification
Verification systems may be needed to ensure compliance with Do Not
Track. Such systems are outside the scope of this document.
11. Security Considerations
This document does not introduce any known security considerations.
12. Privacy Considerations
User agent implementation of Do Not Track contributes a small amount
of fingerprintable information (see [Eckersley10] and [Mayer09]).
The amount of information depends on the degree of adoption.
Supposing, for example, that 10% of user agents have Do Not Track
enabled, the header adds only -log2(0.1) (roughly 3.3) bits of
identifying information to the user agent. Relative to other sources
of fingerprintable information Do Not Track is of minimal concern.
13. IANA Considerations
This specification calls for a new IANA provisional message header
field registration, in accordance with [RFC3864].
Header field name: see Section 5
Applicable protocol: http ([RFC2616])
Status: standard
Author/Change controller: IETF
Specification document: this document
14. References
14.1. Normative References
[RFC0920] Postel, J. and J. Reynolds, "Domain requirements",
RFC 920, October 1984.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Mayer, et al. Expires September 8, 2011 [Page 9]
Internet-Draft Do Not Track March 2011
[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.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
14.2. Informative References
[Aggarwal10]
Aggarwal, G., Bursztein, E., Jackson, C., and D. Boneh,
"An Analysis of Private Browsing Modes in Modern
Browsers", 2010, <http://crypto.stanford.edu/~dabo/pubs/
papers/privatebrowsing.pdf>.
[Eckersley10]
Eckersley, P., "How Unique Is Your Web Browser?", 2010,
<https://panopticlick.eff.org/browser-uniqueness.pdf>.
[Evercookie]
Kamkar, S., "Evercookie", September 2010,
<http://samy.pl/evercookie/>.
[HistoryOfDNT]
Soghoian, C., "The History of the Do Not Track Header",
January 2011, <http://paranoia.dubfire.net/2011/01/
history-of-do-not-track-header.html>.
[Krishnamurthy10]
Krishnamurthy, B., "Privacy Leakage on the Internet",
March 2010,
<http://www.ietf.org/proceedings/77/slides/
plenaryt-5.pdf>.
[Mayer09] Mayer, J., ""Any person... a pamphleteer": Internet
Anonymity in the Age of Web 2.0", April 2009,
<http://stanford.edu/~jmayer/papers/thesis09.pdf>.
[McKinley08]
McKinley, K., "Cleaning Up After Cookies", December 2010,
<https://www.isecpartners.com/files/
iSEC_Cleaning_Up_After_Cookies.pdf>.
[Narayanan08]
Mayer, et al. Expires September 8, 2011 [Page 10]
Internet-Draft Do Not Track March 2011
Narayanan, A. and V. Shmatikov, "Robust De-anonymization
of Large Sparse Datasets", 2008,
<http://www.cs.utexas.edu/~shmat/shmat_oak08netflix.pdf>.
[Narayanan09]
Narayanan, A. and V. Shmatikov, "De-anonymizing Social
Networks", 2009,
<http://www.cs.utexas.edu/~shmat/shmat_oak09.pdf>.
[PublicSuffix]
"The Public Suffix List", <http://publicsuffix.org/>.
[Turow09] Turow, J., King, J., Hoofnagle, C., Bleakley, A., and M.
Hennessy, "Americans Reject Tailored Advertising and Three
Activities that Enable It", September 2009,
<http://ssrn.com/abstract=1478214>.
[WebsNewGoldMine]
Angwin, J., "The Web's New Gold Mine: Your Secrets",
July 2010, <http://online.wsj.com/article/
SB10001424052748703940904575395073512989404.html>.
Authors' Addresses
Jonathan Mayer
Stanford University
URI: http://jonathanmayer.net
Arvind Narayanan
Stanford University
URI: http://randomwalker.info
Sid Stamm
Mozilla
URI: http://sidstamm.com
Mayer, et al. Expires September 8, 2011 [Page 11]