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]