add sections on introduction and security considerations

This commit is contained in:
Frederik Ring 2021-03-26 08:58:11 +01:00
parent cc816f4cb4
commit 68a7317ef4

View File

@ -32,13 +32,17 @@ informative:
--- abstract --- abstract
Privacy has become an important feature for users of websites and services. This document propopes a well-defined way for websites and services to signal their usage of analytics and tracking software to users and tooling used by users. analytics.txt aims to be an elaborate standard that describes the usage of analytics and tracking in a non-biased way that is understandable both for a non-technical audience, but also useful for consumption by tools and software. Privacy has become an important feature for users of websites and services. This document propopes a well-defined way for websites and services to disclose their usage of analytics and tracking software to users and tooling used by users. analytics.txt aims to be an elaborate standard that describes the usage of analytics and tracking software in a non-biased way that is understandable both for a non-technical audience, but also useful for consumption by tools and software.
--- middle --- middle
# Introduction # Introduction
TODO Introduction The usage of analytics software and user tracking on websites is becoming an increasingly important factor for users on the internet. Yet, there is no well-defined way of accessing such information in a standardized way. Legislation only covers certain technological implementations, incentivizing software to find workarounds, thus being able hiding their presence from users. Automated audits are limited to aspects that are possible to detect in clients.
This document defines a way to specify the privacy related characteristics of analytics and tracking software. We aim for this information to be consumable both by humans as well as other software. For example, search engines or browser extensions could make use of this data and display information to users.
The file "analytics.txt" is not intended to replace the requirement for complying to certain regulations, but supposed to give insights beyond the scope of these regulations.
# Conventions and Definitions # Conventions and Definitions
@ -53,12 +57,12 @@ The term "implementors" refers to the providers of services and websites that wi
This document defines a text file format that can be used by implementors to signal information about their usage of analytics software to both users and other software. This document defines a text file format that can be used by implementors to signal information about their usage of analytics software to both users and other software.
By convention, this file is called analytics.txt. Its location and scope are described in section 3. By convention, this file is called analytics.txt. Its location and scope are described in {{location}}.
This text file contains multiple fields with different values. A field contains a "name" which is the first part of a field all the way up to the colon (for example: "Contact:") and follows the syntax This text file contains multiple fields with different values. A field contains a "name" which is the first part of a field all the way up to the colon (for example: "Contact:") and follows the syntax
defined for "field-name" in section 3.6.8 of {{?RFC5322}}. Field names are case-insensitive (as per section 2.3 of {{?RFC5234}}). The "value" comes after the field name and follows the syntax defined for "unstructured" in section 3.2.5 of {{?RFC5322}}. The file MAY also contain blank lines. defined for "field-name" in section 3.6.8 of {{?RFC5322}}. Field names are case-insensitive (as per section 2.3 of {{?RFC5234}}). The "value" comes after the field name and follows the syntax defined for "unstructured" in section 3.2.5 of {{?RFC5322}}. The file MAY also contain blank lines.
A field MUST always consist of a name and a value (for example: "Contact: mailto:data-protection@example.com). An analytics.txt file can have an unlimited number of fields. 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: "Compliance: gdpr, ccpa") using the "," (%x2c). Unless otherwise indicated in a definition of a particular field, a field MAY NOT appear multiple times. A field MUST always consist of a name and a value (for example: "Contact: mailto:privacy@example.com). An analytics.txt file can have an unlimited number of fields. 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: "Compliance: gdpr, ccpa") using the "," (%x2c). Unless otherwise indicated in a definition of a particular field, a field MAY NOT appear multiple times.
Implementors should be aware that some of the fields may contain URIs using percent-encoding (as per section 2.1 of {{?RFC3986}}). Implementors should be aware that some of the fields may contain URIs using percent-encoding (as per section 2.1 of {{?RFC3986}}).
@ -90,7 +94,7 @@ Field names are case-insensitive, yet implementors SHOULD use the capitalized st
Field values are case-insensitive. In case a field contains an enumeration, implementors MUST refer to the allowed values given by the specification. Field values are case-insensitive. In case a field contains an enumeration, implementors MUST refer to the allowed values given by the specification.
### Contact ### Contact {#contact-field}
This REQUIRED field holds an email address that can be used for contacting the provider of the analytics.txt file. It shall be used for inquiries about the correctness and additions to the data provided in the file. This REQUIRED field holds an email address that can be used for contacting the provider of the analytics.txt file. It shall be used for inquiries about the correctness and additions to the data provided in the file.
@ -274,7 +278,7 @@ Compliance: gdpr
Vendors: offen Vendors: offen
``` ```
# Location of the analytics.txt file # Location of the analytics.txt file {#location}
By default, an analytics.txt file SHOULD be placed in the ".well-known" path as per {{!RFC8615}} of a domain name or IP address. In case implementors are unable to meet this requirement, two other options are available. By default, an analytics.txt file SHOULD be placed in the ".well-known" path as per {{!RFC8615}} of a domain name or IP address. In case implementors are unable to meet this requirement, two other options are available.
@ -308,15 +312,27 @@ An analytics.txt file MUST only apply to the domain or IP address in the URI use
## Incorrect or stale information ## Incorrect or stale information
TODO incorrect information If information given in an "analytics.txt" file is incorrect or not kept up to date, this can result in usage of services under wrong assumptions in the realm of privacy, thus exposing users to possibly unwanted data collection and handling. Not having an "analytics.txt" file may be preferable to having stale information in this file. Implementors must use the "Contact" field (see {{contact-field}}) to allow inquiries about the correctness of the given information.
## Spam ## Spam
TODO Spam Implementors should be aware that disclosing mandatory contact information in such a file exposes them to possible Spam schemes or spurious requests.
# Multi-user Environments
In multi-user / multi-tenant environments, it may possible for a user to take over the location of the "/.well-known/security.txt" file. Organizations should ensure the ".well-known" location is properly protected. Implementors can use other locations as per {{location}}.
# IANA Considerations # IANA Considerations
This document has no IANA actions. ## Well-Known URIs registry
The "Well-Known URIs" registry should be updated with the following additional values (using the template from {{!RFC8615}}):
URI suffix: analytics.txt
Specification document(s): this document
Status: permanent
--- back --- back