idnits 2.17.1 draft-ring-analyticstxt-02.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 17 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: A field MUST always consist of a name and a value (for example: "Author: Jane Doe jane.doe@example.com (mailto:jane.doe@example.com)"). Each field MUST appear on its own line. Unless specified otherwise by the field definition, multiple values MUST be chained together for a single field (for example: "Implements: gdpr, ccpa") using the "," character (%x2c). A field MAY NOT appear multiple times. -- The document date (18 August 2021) is 975 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Ring 3 Internet-Draft H. Niefeld 4 Intended status: Informational Offen 5 Expires: 19 February 2022 18 August 2021 7 A File Format for the Discoverable Use of Analytics 8 draft-ring-analyticstxt-02 10 Abstract 12 Internet privacy has become an important feature for users of 13 websites and services. This document proposes a way for websites and 14 services to declare and disclose their usage of analytics and 15 tracking software. analytics.txt aims to be an elaborate file format 16 that describes the privacy related characteristics of analytics and 17 tracking software in a non-biased way. An analytics.txt file is 18 understandable for a non-technical audience, while also useful for 19 the automated consumption by tools and software. 21 Discussion Venues 23 This note is to be removed before publishing as an RFC. 25 Source for this draft and an issue tracker can be found at 26 https://github.com/offen/analyticstxt. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 19 February 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Scope of this proposal . . . . . . . . . . . . . . . . . 3 64 1.2.1. About providing a human readable format . . . . . . . 3 65 1.3. Definition of the term "analytics" in the scope of this 66 document . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.4. Verifying the provided information . . . . . . . . . . . 4 68 1.4.1. Non-biased . . . . . . . . . . . . . . . . . . . . . 4 69 1.4.2. Non-canonical . . . . . . . . . . . . . . . . . . . . 4 70 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 71 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. Comments . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.2. Line Separators . . . . . . . . . . . . . . . . . . . . . 6 74 3.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 6 75 3.4. Field Definitions . . . . . . . . . . . . . . . . . . . . 6 76 3.4.1. Author . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.4.2. Collects . . . . . . . . . . . . . . . . . . . . . . 6 78 3.4.3. Stores . . . . . . . . . . . . . . . . . . . . . . . 8 79 3.4.4. Uses . . . . . . . . . . . . . . . . . . . . . . . . 9 80 3.4.5. Allows . . . . . . . . . . . . . . . . . . . . . . . 10 81 3.4.6. Retains . . . . . . . . . . . . . . . . . . . . . . . 10 82 3.4.7. Honors . . . . . . . . . . . . . . . . . . . . . . . 11 83 3.4.8. Tracks . . . . . . . . . . . . . . . . . . . . . . . 11 84 3.4.9. Varies . . . . . . . . . . . . . . . . . . . . . . . 12 85 3.4.10. Shares . . . . . . . . . . . . . . . . . . . . . . . 12 86 3.4.11. Implements . . . . . . . . . . . . . . . . . . . . . 13 87 3.4.12. Deploys . . . . . . . . . . . . . . . . . . . . . . . 14 88 3.5. Examples of analytics.txt files . . . . . . . . . . . . . 14 89 3.5.1. A site using analytics . . . . . . . . . . . . . . . 14 90 3.5.2. Specifying required fields only . . . . . . . . . . . 14 91 3.5.3. A site not using any analytics . . . . . . . . . . . 15 92 4. Location of the analytics.txt file . . . . . . . . . . . . . 15 93 4.1. Alternatives . . . . . . . . . . . . . . . . . . . . . . 15 94 4.1.1. link Tag . . . . . . . . . . . . . . . . . . . . . . 15 95 4.1.2. HTTP Header . . . . . . . . . . . . . . . . . . . . . 15 96 4.2. Precedence . . . . . . . . . . . . . . . . . . . . . . . 15 97 4.3. Scope of a file . . . . . . . . . . . . . . . . . . . . . 16 99 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 100 5.1. Incorrect or stale information . . . . . . . . . . . . . 16 101 5.2. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 5.3. Multi-user environments . . . . . . . . . . . . . . . . . 16 103 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 104 6.1. Well-Known URIs registry . . . . . . . . . . . . . . . . 17 105 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 106 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 107 7.2. Informative References . . . . . . . . . . . . . . . . . 17 108 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 18 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 111 1. Introduction 113 1.1. Motivation 115 User tracking and the utilization of analytics software on websites 116 has become a widely employed routine, visibly and invisibly affecting 117 the way the user facing internet works and behaves. Yet, there is no 118 well-defined way of accessing information about what software is 119 being used and what kind of data it is collecting in a standardized 120 way. Legislation can only ever cover a subset of the range of 121 existing technological implementations, creating incentives for 122 software to find workarounds, thus allowing them to hide their 123 presence from users. Automated audits are limited to aspects that 124 are possible to detect in clients, but cannot disclose other 125 important implementation details. 127 1.2. Scope of this proposal 129 This document defines a way to specify the privacy related 130 characteristics of analytics and tracking software. We aim for this 131 information to be consumable both by humans as well as software. 133 The file "analytics.txt" is not intended to replace the requirement 134 for complying with existing regulations, but supposed to give 135 insights beyond the scope of these regulations. 137 1.2.1. About providing a human readable format 139 A fundamental design goal of the "analytics.txt" format is to make 140 such a file human readable. While the percentage of consumers that 141 are actually human beings will likely be low - browser extensions or 142 search engines would be good examples of possible consumers - this 143 tenet can drive the specification into a direction where the format 144 will focus on providing information that is useful for human beings, 145 even when captured and processed further by other software. 147 1.3. Definition of the term "analytics" in the scope of this document 149 Analytics as referred to in this document involves the collection of 150 usage statistics in order to generate reports that can help the 151 providers of websites and services to better understand and optimize 152 their services towards real world user behavior. This can also 153 include measuring different content against different groups of 154 users. 156 1.4. Verifying the provided information 158 "analytics.txt" is designed to provide insights beyond what is 159 technically auditable from a client perspective. While some 160 characteristics could be determined automatically or manually at 161 client level, others won't, and will rely on implementors providing 162 correct information about what is happening at layers that are opaque 163 to users. This means consumers of an "analytics.txt" file will 164 implictly need to trust the implementor to provide correct 165 information, implicating two design goals for the format (technical 166 implications are discussed in Section 5.1). 168 1.4.1. Non-biased 170 All of the given datapoints are purely informational, there is no 171 right or wrong option to choose from, and the format will never 172 provide guidelines on how to assess or rate an "analytics.txt" file. 173 Based on this, implementors don't have strong incentives for 174 providing incorrect information, but choose implementation because 175 they are wishing to disclose information about their site that they 176 otherwise couldn't. 178 1.4.2. Non-canonical 180 An "analytics.txt" file should never be the canonical source of truth 181 for making automated decisions or ratings about a site. It is 182 supposed to be one of multiple signals that can be used for assessing 183 the behavior of a website, creating the possibility to connect and 184 compare the provided data with what has been surveyed using other 185 channels of information. 187 2. Conventions and Definitions 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 191 "OPTIONAL" in this document are to be interpreted as described in BCP 192 14 [RFC2119] [RFC8174] when, and only when, they appear in all 193 capitals, as shown here. 195 The term "implementors" refers to the providers of services and 196 websites that wish to use an analytics.txt file. 198 3. Specification 200 This document defines a text file format that can be used by 201 implementors to signal information about their usage of analytics 202 software to both users and software. 204 By convention, this file is called "analytics.txt". Its location and 205 scope are described in Section 4. 207 This text file contains multiple fields with different values. A 208 field contains a "name" which is the first part of a field all the 209 way up to the colon (for example: "Author:") and follows the syntax 210 defined for "field-name" in section 3.6.8 of [RFC5322]. Field names 211 are case-insensitive (as per section 2.3 of [RFC5234]). The "value" 212 comes after the field name and follows the syntax defined for 213 "unstructured" in section 3.2.5 of [RFC5322]. The file MAY also 214 contain blank lines and comments. 216 A field MUST always consist of a name and a value (for example: 217 "Author: Jane Doe jane.doe@example.com 218 (mailto:jane.doe@example.com)"). Each field MUST appear on its own 219 line. Unless specified otherwise by the field definition, multiple 220 values MUST be chained together for a single field (for example: 221 "Implements: gdpr, ccpa") using the "," character (%x2c). A field 222 MAY NOT appear multiple times. 224 Implementors SHOULD aim for authoring an analytics.txt file that is 225 easy to understand by non-technical audiences. 227 3.1. Comments 229 Any line beginning with the "#" (%x23) symbol MUST be interpreted as 230 a comment. The content of the comment may contain any ASCII or 231 Unicode characters in the %x21-7E and %x80-FFFFF ranges plus the tab 232 (%x09) and space (%x20) characters. 234 Example: 236 # This is a comment 238 Implementors SHOULD make deliberate use of comments to make an 239 analytics.txt file more accessible for non-technical audiences. 241 3.2. Line Separators 243 Every line MUST end either with a carriage return and line feed 244 characters (CRLF / %x0D %x0A) or just a line feed character (LF / 245 %x0A). 247 3.3. Extensibility 249 Like many other formats and protocols, this format may need to be 250 extended over time to fit the ever-changing landscape of the 251 Internet. Special attention is required for defining the allowed 252 values in enumerations to ensure they are a. extendable and b. do not 253 become obsolete too quickly. 255 3.4. Field Definitions 257 Field names are case-insensitive, yet implementors SHOULD use the 258 capitalized style used in this document for consistency. 260 Field values are case-insensitive. Unless otherwise specified, 261 implementors MUST refer to the allowed values for a field given by 262 the specification. 264 3.4.1. Author 266 This REQUIRED field holds an OPTIONAL display name and a REQUIRED 267 email address ("name-addr") as per section 3.4 of [RFC5322] providing 268 information about a person or entity responsible for maintaining the 269 contents of the file. The field MUST contain a valid email address 270 which shall be used for inquiries about the correctness and additions 271 to the data provided in the file. 273 3.4.1.1. Example 275 Author: Jane Doe 277 3.4.2. Collects 279 This REQUIRED multi-value field indicates which potentially privacy 280 relevant user specific data is being collected or used in session 281 identification or other procedures. These values MUST also be 282 specified if a property is not persisted as-is, but stored or 283 processed in a hashed and/or combined form. Some of the allowed 284 values overlap to a certain extent, e.g. a User Agent string might be 285 used in a Browser Fingerprint. 287 3.4.2.1. Allowed values 288 3.4.2.1.1. none 290 No analytics data is collected at all. This value MUST NOT be used 291 in conjunction with other values. 293 3.4.2.1.2. url 295 The URL of a visit, including its path, is collected and used. This 296 MUST also be specified in case URLs are stripped of certain 297 parameters or pseudonymized before being stored. 299 3.4.2.1.3. time 301 The time of visit is collected. 303 3.4.2.1.4. ip-address 305 The request IP address is being used. 307 3.4.2.1.5. geo-location 309 Geographic location of users is determined and used. This could for 310 example be derived from the request IP, or from using browser APIs. 312 3.4.2.1.6. user-agent 314 Information about the utilized User Agent is being collected. 316 3.4.2.1.7. fingerprint 318 Browser Fingerprinting is used. Such mechanisms usually try to 319 compute a unique identifier from properties of the host Operating 320 System, allowing them to re-identify users without having to persist 321 an identifier. 323 3.4.2.1.8. device-type 325 The user's device type (e.g. mobile / tablet / desktop) is being 326 determined and collected. The categories and rules for this 327 distinction might be different for different software solutions. 329 3.4.2.1.9. referrer 331 The Referrer of a visit is collected and used. This MUST also be 332 specified if the referrer value is stripped of potential path 333 fragments. 335 3.4.2.1.10. visit-duration 337 The duration of a visit, either on page- or on session-level is 338 measured and used. 340 3.4.2.1.11. custom-events 342 Custom events like conversion goals are defined and used. This MAY 343 be left out in case the analytics software in use offers such 344 functionality, but implementors chose not to use the feature. 346 3.4.2.1.12. session-recording 348 Detailed behavior like mouse movement and scrolling is recorded and 349 can possibly be played back when analyzing the analytics data. 351 3.4.2.2. Example 353 Collects: url, device-type, referrer 355 3.4.3. Stores 357 This field is REQUIRED unless the only value of the Collects field as 358 per Section 3.4.2 is none. The multi-value field indicates whether 359 data is persisted on the client during the collection of analytics 360 data and declares the browser features used for doing so. In case no 361 data is being persisted at all, the value none MUST be used as the 362 single entry for this field. 364 3.4.3.1. Allowed values 366 3.4.3.1.1. none 368 No data is persisted on the client during the collection of usage 369 data. This value MUST NOT be used in conjunction with other values. 371 3.4.3.1.2. first-party-cookies 373 First party cookies are in use. There is no differentiation between 374 session or persistent cookies, just like HTTP and JavaScript cookies 375 are considered equal. 377 3.4.3.1.3. third-party-cookies 379 Third party cookies are in use. There is no differentiation between 380 session or persistent cookies, just like HTTP and JavaScript cookies 381 are considered equal. 383 3.4.3.1.4. local-storage 385 Data is persisted on the client using non-cookie JavaScript APIs like 386 "localStorage", "sessionStorage", "WebSQL" or "IndexedDB" 388 3.4.3.1.5. cache 390 The analytics software leverages browser cache mechanisms to store 391 identifiers. For example, ETag headers can be used to identify users 392 based on their browser caches' contents. This value is not required 393 in case the analytics software sends static resources with cache 394 headers, but does not make use of the request headers on subsequent 395 requests for purposes other than managing caching of assets. 397 3.4.3.2. Example 399 Stores: first-party-cookies, local-storage 401 3.4.4. Uses 403 This field is REQUIRED unless the only value of the Collects field 404 Section 3.4.2 is none. The multi-value field indicates the technical 405 implementation details for how analytics data is being collected. 407 3.4.4.1. Allowed values 409 3.4.4.1.1. javascript 411 A client-side script is used to collect data. 413 3.4.4.1.2. pixel 415 A static resource - typically a pixel - transferred via HTTP is being 416 used to collect data through the request parameters. 418 3.4.4.1.3. server-side 420 Collection of usage data is happening on the server side at the 421 application layer. 423 3.4.4.1.4. logs 425 Usage data is being calculated from server log files. 427 3.4.4.1.5. other 429 Other techniques that are not described in this section are in use. 431 3.4.4.2. Example 433 Uses: script 435 3.4.5. Allows 437 This field is REQUIRED unless the only value of the Collects field 438 Section 3.4.2 is none. The multi-value field discloses information 439 about whether user consent is being acquired before collecting 440 analytics data, and if it is possible for users to opt out of the 441 collection of usage data. 443 3.4.5.1. Allowed values 445 3.4.5.1.1. none 447 The software does not define a way for users to opt in or opt out of 448 the collection of usage data. This value also applies to scenarios 449 where only a subset of data is collected by default and could be 450 extended by opting in. This value MUST NOT be used in conjunction 451 with other values. 453 3.4.5.1.2. opt-in 455 No usage data is collected before users have given their consent. 457 3.4.5.1.3. opt-out 459 Users can opt out of collection of usage data using a dedicated 460 feature tailored towards the user audience. This value is only 461 applicable in case no data at all is collected after having opted 462 out. 464 3.4.5.2. Example 466 Allows: opt-out 468 3.4.6. Retains 470 This field is REQUIRED unless the only value of the Collects field 471 Section 3.4.2 is none. The single-value field indicates the duration 472 for which the analytics data is being stored before being deleted. 473 This duration MUST also cover periods where data might transition to 474 be stored in aggregated form only. The value is either a duration in 475 days (including the days suffix), or the token "perpetual" in case 476 data is retained without expiring it at some point. A day is defined 477 as 24 hours. In case the retention period does not divide evenly 478 into days, it MUST be brought up to the next round figure. 480 3.4.6.1. Example 482 Retains: 365 days 484 3.4.7. Honors 486 This OPTIONAL, RECOMMENDED multi-value field indicates which browser 487 level privacy controls are being honored when collecting data. 489 3.4.7.1. Allowed values 491 3.4.7.1.1. none 493 Data is collected even if any of the browser settings listed below 494 are in use. This value MUST NOT be used in conjunction with other 495 values. 497 3.4.7.1.2. do-not-track 499 User-Agents that have DoNotTrack [DNT] enabled will be excluded from 500 the collection of analytics data. 502 3.4.7.1.3. global-privacy-control 504 User agents that have Global Privacy Control [GPC] enabled will be 505 excluded from the collection of analytics data. 507 3.4.7.2. Example 509 Honors: do-not-track, global-privacy-control 511 3.4.8. Tracks 513 This OPTIONAL, RECOMMENDED multi-value field indicates the coverage 514 in session and user lifecycle tracking. 516 3.4.8.1. Allowed values 518 3.4.8.1.1. none 520 Each event that is collected is anonymous. There is no way to 521 connect and group multiple pageviews by user or similar. This value 522 MUST NOT be used in conjunction with other values. 524 3.4.8.1.2. sessions 526 Metrics that source from a single browser session can be grouped and 527 distinguished as such. 529 3.4.8.1.3. users 531 Users can be identified across multiple browser sessions. 533 3.4.8.2. Example 535 Tracks: sessions, users 537 3.4.9. Varies 539 This OPTIONAL, RECOMMENDED single-value field indicates the usage of 540 content experiments like A/B testing. It MUST contain a single value 541 only. 543 3.4.9.1. Allowed values 545 3.4.9.1.1. none 547 All users are served the same content without any changes. This 548 value MUST NOT be used in conjunction with other values. 550 3.4.9.1.2. random 552 Content experiments are performed by grouping users randomly into 553 buckets and serving them different content. 555 3.4.9.1.3. geographic 557 Content experiments are performed by targeting user based on their 558 geographic location. 560 3.4.9.1.4. behavioral 562 Content experiments are performed by grouping users into buckets 563 based on their behavior and serving them different content. 565 3.4.9.2. Example 567 Varies: random 569 3.4.10. Shares 571 This OPTIONAL, RECOMMENDED multi-value field indicates whether data 572 is shared with select users, the general public or third parties. 574 3.4.10.1. Allowed values 576 3.4.10.1.1. none 578 The data collected is not shared with any party unless directly 579 affiliated with the implementor, e.g. employees. 581 3.4.10.1.2. per-user 583 Users can access the usage data that is associated with them in a 584 non-aggregated way, isolating all data that is specific to their 585 current means of re-identification. 587 3.4.10.1.3. general-public 589 Usage statistics for the site or service are available to the general 590 public. 592 3.4.10.1.4. third-party 594 Data is being shared non-publicly with third parties. This MUST also 595 be specified when datasets are aggregated or pseudonymized 596 beforehand. 598 3.4.10.2. Example 600 Shares: general-public 602 3.4.11. Implements 604 This OPTIONAL field indicates conformance with existing regulations 605 and legislation. Values for this field SHOULD use all lowercase 606 tokens with whitespace being replaced by the dash character (%x2d). 608 Example values are: 610 * gdpr 612 * ccpa 614 3.4.11.1. Example 616 Implements: gdpr, ccpa 618 3.4.12. Deploys 620 This OPTIONAL field indicates which software is being used for 621 collecting analytics. Values for this field SHOULD use all lowercase 622 tokens with whitespace being replaced by the dash character (%x2d). 624 Example values are: 626 * google-analytics 628 * plausible 630 * hotjar 632 * matomo 634 3.4.12.1. Example 636 Deploys: google-analytics, hotjar 638 3.5. Examples of analytics.txt files 640 3.5.1. A site using analytics 642 # analytics.txt file for www.example.com 643 Author: Jane Doe 645 Collects: url, referrer, device-type 646 Stores: first-party-cookies, local-storage 647 # Usage data is encrypted end-to-end 648 Uses: javascript 649 # Users can also delete their usage data only without opting out 650 Allows: opt-in, opt-out 651 Retains: 186 days 653 # Optional fields 654 Honors: none 655 Tracks: sessions, users 656 Varies: none 657 Shares: per-user 658 Implements: gdpr 660 3.5.2. Specifying required fields only 661 Author: John Doe 662 Collects: url, ip-address, geo-location, user-agent, referrer, device-type, custom-events 663 Stores: none 664 Uses: javascript 665 Allows: none 666 Retains: perpetual 668 3.5.3. A site not using any analytics 670 # analytics.txt file for www.example.com 671 Author: Jane Doe 672 Collects: none 674 4. Location of the analytics.txt file 676 By default, an analytics.txt file SHOULD be placed in the ".well- 677 known" location as per [RFC8615] of a domain name or IP address. 679 4.1. Alternatives 681 In case implementors are unable to meet this requirement, other 682 options are available. 684 4.1.1. link Tag 686 Implementors MAY signal the location of an analytics.txt file in the 687 context of a HTML document using a link element of rel "analytics" 689 Example: 691 693 4.1.2. HTTP Header 695 Implementors MAY send an HTTP header of "X-Analytics-Txt" with a 696 response, sending the URI of the applicable file. 698 Example: 700 X-Analytics-Txt: https://example.com/resources/analytics.txt 702 4.2. Precedence 704 In case multiple of these signals are being used, the precedence 705 taken is: 707 1. X-Analytics-Txt Header 708 2. link element 710 3. ".well-known" location 712 4.3. Scope of a file 714 An analytics.txt file located in the ".well-known" location MUST only 715 apply to the domain or IP address of the URI used to retrieve it, and 716 SHALL NOT apply to any of its subdomains or parent domains. If the 717 location is signaled using the HTTP Header or in the document markup 718 itself, its scope SHALL be limited to the requested resource only. 720 If distributed in non-standard locations, an analytics.txt file MAY 721 also apply to products and services provided by the organization 722 publishing the file (e.g. desktop or mobile applications) and which 723 cannot be mapped to a domain name or IP address. In such cases, 724 implementors MUST add sufficient commentary describing the applicable 725 scope. 727 5. Security Considerations 729 5.1. Incorrect or stale information 731 If information given in an "analytics.txt" file is incorrect or not 732 kept up to date, this can result in usage of services under wrong 733 assumptions, thus exposing users to possibly unwanted data collection 734 and handling. Not having an "analytics.txt" file may be preferable 735 to having incorrect or stale information in this file. This 736 guideline also applies to field level: in case of ambiguities or 737 uncertainties, it's recommended to omit a field or a value rather 738 than providing incorrect information. Implementors MUST use the 739 "Author" field (see Section 3.4.1) to allow inquiries about the 740 correctness of the given information. 742 5.2. Spam 744 Implementors should be aware that disclosing mandatory author 745 information as per Section 3.4.1 in such a file exposes them to 746 possible Spam schemes or spurious requests. 748 5.3. Multi-user environments 750 In multi-user / multi-tenant environments, it may possible for a 751 single user to take over the location of the "/.well-known/ 752 analytics.txt" file which would also apply to others. Organizations 753 should ensure the ".well-known" location is properly protected. 754 Implementors can instead use other locations as per Section 4 in such 755 scenarios. 757 6. IANA Considerations 759 6.1. Well-Known URIs registry 761 The "Well-Known URIs" registry should be updated with the following 762 additional values (using the template from [RFC8615]): 764 URI suffix: analytics.txt 766 Specification document(s): this document 768 Status: permanent 770 7. References 772 7.1. Normative References 774 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 775 Requirement Levels", BCP 14, RFC 2119, 776 DOI 10.17487/RFC2119, March 1997, 777 . 779 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 780 DOI 10.17487/RFC5322, October 2008, 781 . 783 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 784 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 785 May 2017, . 787 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 788 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 789 . 791 7.2. Informative References 793 [DNT] Fielding, R.T. and D. Singer, "Tracking Preference 794 Expression (DNT)", n.d., 795 . 797 [GPC] Berjon, R., Zimmeck, S., Soltani, A., Harbage, D., and P. 798 Snyder, "Global Privacy Control (GPC)", n.d., 799 . 801 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 802 Specifications: ABNF", STD 68, RFC 5234, 803 DOI 10.17487/RFC5234, January 2008, 804 . 806 Appendix A. Acknowledgments 808 The authors would like to acknowledge the feedback and input provided 809 during the creation of this document as given by Michiel Leenaars, 810 Cyrill Kraehenbuehl, Lasse Voss. 812 Authors' Addresses 814 Frederik Ring 815 Offen 817 Email: frederik.ring@gmail.com 819 Hendrik Niefeld 820 Offen 822 Email: hello@niefeld.com