idnits 2.17.1 draft-mayer-do-not-track-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2011) is 4770 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Unknown state RFC: RFC 920 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Mayer 3 Internet-Draft A. Narayanan 4 Intended status: Standards Track Stanford University 5 Expires: September 8, 2011 S. Stamm 6 Mozilla 7 March 7, 2011 9 Do Not Track: A Universal Third-Party Web Tracking Opt Out 10 draft-mayer-do-not-track-00 12 Abstract 14 This document defines the syntax and semantics of Do Not Track, an 15 HTTP header-based mechanism that enables users to express preferences 16 about third-party web tracking. It also provides a standard for how 17 web services should comply with such user preferences. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 8, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Recognition . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6. User Agent Requirements . . . . . . . . . . . . . . . . . . . 5 62 6.1. OPTIONAL Support . . . . . . . . . . . . . . . . . . . . . 5 63 6.2. User Interface RECOMMENDED . . . . . . . . . . . . . . . . 6 64 6.3. Default . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7. Intermediary Requirements . . . . . . . . . . . . . . . . . . 6 66 8. Server Requirements . . . . . . . . . . . . . . . . . . . . . 6 67 8.1. Opt Out . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8.2. Opt In . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.3. Header Not Present . . . . . . . . . . . . . . . . . . . . 6 70 8.4. Response Header RECOMMENDED . . . . . . . . . . . . . . . 6 71 9. Server Policy . . . . . . . . . . . . . . . . . . . . . . . . 7 72 9.1. Definitions of "First Party" and "Third Party" . . . . . . 7 73 9.2. Definition of "Tracking" . . . . . . . . . . . . . . . . . 8 74 9.3. Exceptions . . . . . . . . . . . . . . . . . . . . . . . . 8 75 10. Implementation Considerations . . . . . . . . . . . . . . . . 8 76 10.1. Selective Opt Out and Opt In RECOMMENDED . . . . . . . . . 8 77 10.2. Verification . . . . . . . . . . . . . . . . . . . . . . . 9 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 9 80 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 14.1. Normative References . . . . . . . . . . . . . . . . . . . 9 83 14.2. Informative References . . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Recognition 88 The Do Not Track effort is much broader than this standards document, 89 and we recognize the following individuals without whom Do Not Track 90 would not be possible. For a detailed history of Do Not Track, see 91 [HistoryOfDNT]. We particularly laud the efforts of Christopher 92 Soghoian, whose tireless advocacy led Do Not Track from a technical 93 prototype to a leading privacy proposal. 95 1.1. Contributors 97 Alissa Cooper 98 Center for Democracy and Technology 100 Christopher Soghoian 101 Indiana University 103 Ashkan Soltani 105 Harlan Yu 106 Princeton University 108 1.2. Acknowledgements 110 Peter Eckersley 111 Electronic Frontier Foundation 113 Alexander Fowler 114 Mozilla 116 John Mitchell 117 Stanford University 119 Lee Tien 120 Electronic Frontier Foundation 122 2. Introduction 124 The content of a website is increasingly sourced from numerous 125 entities. This development has given many companies the ability to 126 track users across millions of sites. A number of services now exist 127 solely to track users, often via invisible embedded content. Users 128 widely perceive such third-party tracking as an invasion of privacy 129 (see [WebsNewGoldMine] and [Turow09]). 131 The explosion of stateful (see [Evercookie], [Aggarwal10], and 132 [McKinley08]) and stateless (see [Eckersley10] and [Mayer09]) 133 techniques for tracking users, accompanied by the proliferation of 134 third-party tracking (see [Krishnamurthy10]), prohibit a purely 135 technical means of preventing tracking. Do Not Track is instead a 136 means of allowing users to express their preferences about tracking, 137 including to opt out of tracking some or all of the time. 139 A preference signaling mechanism can, of course, be ignored by bad 140 actors. But the most pervasive third-party trackers are law-abiding 141 commercial enterprises (see [Krishnamurthy10]). This standard 142 intends to aid these fair players by allowing them to honor a user's 143 preferences. 145 3. Definitions 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 This specification uses the Augmented Backus-Naur Form (ABNF) 152 notation of [RFC5234]. 154 The terms user agent, server, proxy, header, request, and response 155 have the same meaning as in the HTTP/1.1 specification ([RFC2616]). 157 "Explicit user consent" means a user is likely to understand and 158 accept the choice she makes. Agreement to a terms of service or 159 privacy policy does not, in general, constitute explicit user 160 consent. 162 A "functional entity" is a commercial, nonprofit, or government 163 organization, a subsidiary or unit of such an organization, or a 164 person. 166 "THIRD-PARTY TRACKING" is shorthand for activities covered by 167 Section 9.1 and Section 9.2, and not excepted by Section 9.3. 169 A "public suffix" is a domain name under which users can register 170 domain names. A list is maintained at [PublicSuffix]. This document 171 uses public suffixes instead of top-level domains (see [RFC0920]) 172 because they more accurately reflect organizational boundaries. 174 "Protocol logs" means logs for all network protocols that arise from 175 an HTTP request and response. 177 4. Overview 179 This document is organized into two parts. The first part details 180 the technical implementation of Do Not Track: the header syntax 181 (Section 5), user agent requirements (Section 6), intermediary 182 requirements (Section 7), and server requirements (Section 8). The 183 second part provides the policy a server implementing Do Not Track 184 must observe (Section 9). 186 4.1. Example 188 In the status quo: A user navigates a sequence of popular websites, 189 many of which incorporate content from a major advertising network. 190 In addition to delivering advertisements, the advertising network 191 assigns a unique cookie to the user agent and compiles observations 192 of the user's browsing habits. 194 With Do Not Track: A user enables Do Not Track in her web browser. 195 She navigates a sequence of popular websites, many of which 196 incorporate content from a major advertising network. The 197 advertising network delivers advertisements, but refrains from THIRD- 198 PARTY TRACKING of the user. 200 5. Header Syntax 202 The Do Not Track HTTP header, "DNT", must take one of two values: "1" 203 ("opt out") or "0" ("opt in"). All other values are reserved. 205 DNT = "DNT" ":" BIT 207 For clarity this document refers to an opt-out header as OPT-OUT, an 208 opt-in header as OPT-IN, and the absence of a header as NO-EXPRESSED- 209 PREFERENCE. 211 6. User Agent Requirements 213 6.1. OPTIONAL Support 215 A user agent MAY include a Do Not Track header in any HTTP request. 217 6.2. User Interface RECOMMENDED 219 A user agent that implements Do Not Track SHOULD provide a user 220 interface for modifying preferences. The user interface design is 221 left to the user agent. 223 6.3. Default 225 A user agent MAY adopt NO-EXPRESSED-PREFERENCE or OPT-OUT by default. 226 It MUST NOT transmit OPT-IN without explicit user consent. 228 7. Intermediary Requirements 230 A proxy or other intermediary MUST NOT add, remove, or modify a Do 231 Not Track header without explicit user consent. 233 8. Server Requirements 235 8.1. Opt Out 237 In processing a request that includes an OPT-OUT header, a server 238 MUST NOT perform THIRD-PARTY TRACKING. The server MUST instruct the 239 user agent to delete any data previously stored for THIRD-PARTY 240 TRACKING. 242 8.2. Opt In 244 In processing a request that includes an OPT-IN header, a server MAY 245 perform THIRD-PARTY TRACKING. 247 8.3. Header Not Present 249 In processing a NO-EXPRESSED-PREFERENCE request, a server MAY perform 250 THIRD-PARTY TRACKING. The functional entity responsible for the 251 server MUST NOT draw any inferences about a user's preferences from 252 the absence of an OPT-OUT or OPT-IN header. 254 8.4. Response Header RECOMMENDED 256 In responding to a request that includes a Do Not Track header, a 257 third-party server that complies with Do Not Track SHOULD echo the 258 request header. For example: 260 GET /thirdpartycontent.html HTTP/1.1 261 Host: thirdparty.example.com 262 DNT: 1 264 HTTP/1.1 200 OK 265 Date: Mon, 7 March 2011 01:23:45 GMT 266 Server: Apache/2.2.17 (Unix) 267 Content-Length: 123 268 Connection: close 269 Content-Type: text/html; charset=UTF-8 270 DNT: 1 272 This feature is intended to aid in the decentralized collection of 273 statistics about the Do Not Track mechanism, including adoption rates 274 and intermediary operations. It is also intended to clearly identify 275 whether a request was processed in compliance with Do Not Track. 277 9. Server Policy 279 This section specifies the requirements for server compliance with a 280 Do Not Track OPT-OUT: A server acting in a third-party capacity (see 281 Section 9.1) MUST NOT track (see Section 9.2) a user or user agent 282 unless subject to an exception (see Section 9.3). 284 9.1. Definitions of "First Party" and "Third Party" 286 A first party is a functional entity with which the user reasonably 287 expects to exchange data. In most cases the functional entity 288 responsible for the web page a user has navigated to is the sole 289 first party. 291 A third party is a functional entity with which the user does not 292 reasonably expect to share data. In general advertising networks, 293 analytics services, and social plug-in providers are third parties. 294 To a first approximation, a functional entity is a third party if it 295 differs from the current page in: 297 1. Public suffix plus one domain name (PS+1), or 298 2. PS+1 authoritative name servers, or 299 3. PS+1 of CNAME records. 301 We emphasize that this rule is only an approximation. Many first 302 parties span several domain names, and many third parties are located 303 at a subdomain of a first party. 305 In practice a third party usually interacts with a user agent via 306 content embedded on a first-party webpage. A third party could also 307 receive data from a first party. 309 9.2. Definition of "Tracking" 311 Tracking includes collection, retention, and use of all data related 312 to the request and response. 314 9.3. Exceptions 316 As a general guideline, exceptions to Do Not Track are warranted when 317 commercial interests substantially outweigh privacy and verification 318 interests. The following activities are excepted: 320 1. Tracking of users who have explicitly consented to tracking, such 321 as by enabling a checkbox in a preferences menu on the first- 322 party website of the tracking service. 323 2. Data obtained by a third party exclusively on behalf of and for 324 the use of a first party. 325 3. Data that is, with high confidence, not linkable to a specific 326 user or user agent. This exception includes statistical 327 aggregates of protocol logs, such as pageview statistics, so long 328 as the aggregator takes reasonable steps to ensure the data does 329 not reveal information about individual users, user agents, 330 devices, or log records. It also includes highly non-unique data 331 stored in the user agent, such as cookies used for advertising 332 frequency capping or sequencing. This exception does not include 333 anonymized data, which recent work has shown to be often re- 334 identifiable (see [Narayanan09] and [Narayanan08]). 335 4. Protocol logs, not aggregated across first parties, and subject 336 to a two week retention period. 337 5. Protocol logs used solely for advertising fraud detection, and 338 subject to a one month retention period. 339 6. Protocol logs used solely for security purposes such as intrusion 340 detection and forensics, and subject to a six month retention 341 period. 342 7. Protocol logs used solely for financial fraud detection, and 343 subject to a six month retention period. 345 To ensure data allowed for only specific uses is adequately 346 protected, functional entities SHOULD implement strong internal 347 controls. 349 10. Implementation Considerations 351 10.1. Selective Opt Out and Opt In RECOMMENDED 353 A user agent implementing Do Not Track SHOULD allow a user to 354 selectively opt out of or opt into tracking on specific first-party 355 websites, by specific third parties, or by specific third parties on 356 specific first-party websites. Definition and implementation of 357 selective opt out and opt in is outside the scope of this document. 359 10.2. Verification 361 Verification systems may be needed to ensure compliance with Do Not 362 Track. Such systems are outside the scope of this document. 364 11. Security Considerations 366 This document does not introduce any known security considerations. 368 12. Privacy Considerations 370 User agent implementation of Do Not Track contributes a small amount 371 of fingerprintable information (see [Eckersley10] and [Mayer09]). 372 The amount of information depends on the degree of adoption. 373 Supposing, for example, that 10% of user agents have Do Not Track 374 enabled, the header adds only -log2(0.1) (roughly 3.3) bits of 375 identifying information to the user agent. Relative to other sources 376 of fingerprintable information Do Not Track is of minimal concern. 378 13. IANA Considerations 380 This specification calls for a new IANA provisional message header 381 field registration, in accordance with [RFC3864]. 383 Header field name: see Section 5 384 Applicable protocol: http ([RFC2616]) 385 Status: standard 386 Author/Change controller: IETF 387 Specification document: this document 389 14. References 391 14.1. Normative References 393 [RFC0920] Postel, J. and J. Reynolds, "Domain requirements", 394 RFC 920, October 1984. 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 400 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 401 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 403 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 404 Procedures for Message Header Fields", BCP 90, RFC 3864, 405 September 2004. 407 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 408 Specifications: ABNF", STD 68, RFC 5234, January 2008. 410 14.2. Informative References 412 [Aggarwal10] 413 Aggarwal, G., Bursztein, E., Jackson, C., and D. Boneh, 414 "An Analysis of Private Browsing Modes in Modern 415 Browsers", 2010, . 418 [Eckersley10] 419 Eckersley, P., "How Unique Is Your Web Browser?", 2010, 420 . 422 [Evercookie] 423 Kamkar, S., "Evercookie", September 2010, 424 . 426 [HistoryOfDNT] 427 Soghoian, C., "The History of the Do Not Track Header", 428 January 2011, . 431 [Krishnamurthy10] 432 Krishnamurthy, B., "Privacy Leakage on the Internet", 433 March 2010, 434 . 437 [Mayer09] Mayer, J., ""Any person... a pamphleteer": Internet 438 Anonymity in the Age of Web 2.0", April 2009, 439 . 441 [McKinley08] 442 McKinley, K., "Cleaning Up After Cookies", December 2010, 443 . 446 [Narayanan08] 447 Narayanan, A. and V. Shmatikov, "Robust De-anonymization 448 of Large Sparse Datasets", 2008, 449 . 451 [Narayanan09] 452 Narayanan, A. and V. Shmatikov, "De-anonymizing Social 453 Networks", 2009, 454 . 456 [PublicSuffix] 457 "The Public Suffix List", . 459 [Turow09] Turow, J., King, J., Hoofnagle, C., Bleakley, A., and M. 460 Hennessy, "Americans Reject Tailored Advertising and Three 461 Activities that Enable It", September 2009, 462 . 464 [WebsNewGoldMine] 465 Angwin, J., "The Web's New Gold Mine: Your Secrets", 466 July 2010, . 469 Authors' Addresses 471 Jonathan Mayer 472 Stanford University 474 URI: http://jonathanmayer.net 476 Arvind Narayanan 477 Stanford University 479 URI: http://randomwalker.info 481 Sid Stamm 482 Mozilla 484 URI: http://sidstamm.com