Skip to main content

A File Format to Aid in Consumer Privacy Enforcement, Research, and Tools
draft-colwell-privacy-txt-01

Document Type Active Internet-Draft (individual)
Authors Nick Sullivan , Louise Van der Peet , Georgios Smaragdakis , Brien Colwell
Last updated 2024-06-27
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-colwell-privacy-txt-01
Network Working Group                                        N. Sullivan
Internet-Draft                               Cryptography Consulting LLC
Intended status: Informational                             L. V. D. Peet
Expires: 28 December 2024                                 G. Smaragdakis
                                                                TU Delft
                                                              B. Colwell
                                                         BringYour, Inc.
                                                            26 June 2024

  A File Format to Aid in Consumer Privacy Enforcement, Research, and
                                 Tools
                      draft-colwell-privacy-txt-01

Abstract

   This proposal outlines a new file format called privacy.txt.  It
   follows similar placement on a web server as robots.txt [RFC9309],
   security.txt [RFC9116], or ads.txt [ADS-TXT], in the / directory or
   /.well-known directory.

   The file format adds structured data for three areas: 1.  A machine
   parsable and complete privacy policy 2.  Consumer actions under their
   privacy rights 3.  Cookie disclosures

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://www.privacytxt.dev.  Status information for this document may
   be found at https://datatracker.ietf.org/doc/draft-colwell-privacy-
   txt/.

   Discussion of this document takes place on the draft-colwell-privacy-
   txt Working Group mailing list (mailto:draft-colwell-privacy-
   txt@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/draft-colwell-privacy-txt/.
   Subscribe at https://www.ietf.org/mailman/listinfo/draft-colwell-
   privacy-txt/.

   Source for this draft and an issue tracker can be found at
   https://github.com/https://github.com/grittygrease/draft-colwell-
   privacy-txt.

Sullivan, et al.        Expires 28 December 2024                [Page 1]
Internet-Draft           Privacy.txt File Format               June 2024

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 https://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 28 December 2024.

Copyright Notice

   Copyright (c) 2024 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 (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  General file format . . . . . . . . . . . . . . . . . . .   4
     1.2.  File placement  . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Valid value formats . . . . . . . . . . . . . . . . . . .   4
       1.3.1.  NAME  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.2.  COUNTRY_CODE  . . . . . . . . . . . . . . . . . . . .   5
       1.3.3.  LANGUAGE_CODE . . . . . . . . . . . . . . . . . . . .   5
       1.3.4.  CONSENT_PRESENT . . . . . . . . . . . . . . . . . . .   5
       1.3.5.  CONSENT_PLATFORM  . . . . . . . . . . . . . . . . . .   5
       1.3.6.  DURATION  . . . . . . . . . . . . . . . . . . . . . .   5
     1.4.  A machine parsable and complete privacy policy  . . . . .   5
       1.4.1.  Issuer information  . . . . . . . . . . . . . . . . .   5
       1.4.2.  Privacy policy text . . . . . . . . . . . . . . . . .   6
       1.4.3.  Privacy policy URL  . . . . . . . . . . . . . . . . .   6
     1.5.  Consumer actions under their privacy rights . . . . . . .   6

Sullivan, et al.        Expires 28 December 2024                [Page 2]
Internet-Draft           Privacy.txt File Format               June 2024

       1.5.1.  Privacy contact email . . . . . . . . . . . . . . . .   7
       1.5.2.  Actions . . . . . . . . . . . . . . . . . . . . . . .   7
     1.6.  Cookie disclosures  . . . . . . . . . . . . . . . . . . .   8
       1.6.1.  Consent banner  . . . . . . . . . . . . . . . . . . .   8
       1.6.2.  Consent platform name . . . . . . . . . . . . . . . .   8
       1.6.3.  Cookies . . . . . . . . . . . . . . . . . . . . . . .   9
   2.  Other records . . . . . . . . . . . . . . . . . . . . . . . .  10
   3.  Conventions and Definitions . . . . . . . . . . . . . . . . .  10
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Consumers in many parts of the world have extensive privacy rights
   under laws such as the GDPR (https://gdpr.eu/tag/gdpr/), the CCPA
   (https://oag.ca.gov/privacy/ccpa).  However, without some
   formalization of a service's privacy policy, it is difficult or often
   intractable for consumers to exercise those rights; enforcement to
   verify compliance with laws and develop effective monitoring; and
   researchers and technologists to develop tools to allow greater
   adoption and success of privacy practices.

   Consumer data originally gets into the cloud by connections from
   consumer devices to web servers in the cloud.  To be able to audit
   and technically enforce privacy it must be possible to track the
   privacy policies applied to every byte of consumer data entering the
   cloud.  However, currently the association between a web request and
   the privacy policy is tenuous, leading to the possibility of
   incorrect or unverifiable consumer data usage at the very source.
   This proposal fills that hole by associating structured privacy data
   with every web server.  Just like HTTPS security can be technically
   enforced, this proposal makes it possible to technically enforce
   privacy by verifying that the structured privacy information exists
   and is in good standing before sending data to the server.

   This proposal outlines a new file format called privacy.txt.  The
   file format adds structured data for three areas: 1.  A machine-
   parsable and complete privacy policy 2.  Consumer actions under their
   privacy rights 3.  Cookie disclosures

Sullivan, et al.        Expires 28 December 2024                [Page 3]
Internet-Draft           Privacy.txt File Format               June 2024

1.1.  General file format

   The file format is UTF8 text [RFC3629] and lists Field:Value, one per
   line. \n is used a line break.  Excess whitespace and lines that
   start with # are ignored.  All field are NOT case sensitive unless
   mentioned otherwise.  Each field MUST appear on its own line.  Unless
   otherwise specified by the field definition, multiple values MUST NOT
   be chained together for a single field.  Unless otherwise indicated
   in a definition of a particular field, a field MAY 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]) and mailto
   URIs (as per [RFC6068]).

1.2.  File placement

   For web-based services, organizations MUST place the "privacy.txt"
   file under the "/.well-known/" path, e.g., https://example.com/.well-
   known/privacy.txt as per [RFC8615] of a domain name or IP address.
   For legacy compatibility, a "privacy.txt" file might be placed at the
   top-level path or redirect (as per Section 6.4 of [RFC7231]) to the
   "privacy.txt" file under the "/.well-known/" path.  If a
   "privacy.txt" file is present in both locations, the one in the
   "/.well-known/" path MUST be used.

   The file MUST be accessed via HTTP 1.0 or a higher version, and the
   file access MUST use the "https" scheme (as per Section 2.7.2 of
   [RFC7230]).  It MUST have a Content-Type of "text/plain" with the
   default charset parameter set to "utf-8" (as per Section 4.1.3 of
   [RFC2046]).

   Retrieval of "privacy.txt" files and resources indicated within such
   files may result in a redirect (as per Section 6.4 of [RFC7231]).

1.3.  Valid value formats

1.3.1.  NAME

   A string of maximum 50 characters.  The string can contain any US-
   ASCII characters except for: control characters (ASCII characters 0
   up to 31 and ASCII character 127) or separator characters (space, tab
   and the characters: ( ) < > @ , ; : \ " / [ ] ? = { }).  This field
   is case sensitive.

Sullivan, et al.        Expires 28 December 2024                [Page 4]
Internet-Draft           Privacy.txt File Format               June 2024

1.3.2.  COUNTRY_CODE

   The country code MUST follow 2-letter [ISO3166].

1.3.3.  LANGUAGE_CODE

   The language code MUST follow 2-letter [ISO639].

1.3.4.  CONSENT_PRESENT

   A boolean attribute, using 0 or 1 representing false (0) and true
   (1), whether a consent banner is present.

1.3.5.  CONSENT_PLATFORM

   String attribute can be set to: 1.  Label of consent platforms
   according to [MANAGERS] (extendable) 2. non-specific custom or any
   identifying name if it is a custom banner 3. non-detected when there
   is no banner

1.3.6.  DURATION

   An integer attribute of the duration between 0 and the maximum
   duration. -1 can be used for session cookies.

1.4.  A machine parsable and complete privacy policy

   It is currently difficult to associate a complete privacy policy text
   with a service for a number of reasons.  First, even though it must
   be linked from the company webpage, there is not a canonical URL.
   Second, it is common for services to use client-side rendering,
   interactive elements, break out links for addendums, and server rules
   to prevent machine parsing/scraping.

   This file format proposes two fields for the privacy policy.  One or
   both can be used, depending on the policy format.

   Both privacy policy fields can be used for multi-language support,
   the default entry is the default language of the privacy policy.

1.4.1.  Issuer information

   Mandatory, single entry

   Entity: NAME Entity-country: COUNTRY_CODE

   The legal name of the entity issuing the privacy policy.

Sullivan, et al.        Expires 28 December 2024                [Page 5]
Internet-Draft           Privacy.txt File Format               June 2024

   The current and historical mapping of hostname to entity can be used
   as a canonical key to associate privacy reputation or enforcement
   actions similar to a certificate authority.  This proposal does not
   outline what a privacy authority would look like.

1.4.2.  Privacy policy text

   Optional, single entry

   Privacy-policy-text: URL

   Multi-language support: Privacy-policy-text-[LANGUAGE_CODE]: URL

   A complete privacy policy in a single UTF-8 text file that can be
   downloaded by any user agent or machine tool.  This MUST include all
   addendums in the text file.  It MUST NOT include links.  Information
   about contact and consumer actions are covered in this file format
   and do not need to be linked to in the policy text.

1.4.3.  Privacy policy URL

   Mandatory, single entry

   Privacy-policy: URL

   Multi-language support:

   Privacy-policy-[LANGUAGE_CODE]: URL

   If Privacy-policy-text is present, this can simply point to the
   existing privacy policy, in whatever form it currently exists.
   Otherwise, it must point to a machine parsable/scrapable static HTML
   file that contains the complete policy on a single page.

1.5.  Consumer actions under their privacy rights

   This file format proposed fields to structure the consumer actions
   described in the privacy policy and commonly required by law.
   Currently it is difficult to get even an email that can service
   privacy requests from many top-100 site privacy policies.  There is
   currently no law about how easy it should be to take privacy actions,
   similar to the US CAN-SPAM Act [CAN-SPAM], which led to an industry
   standard one-click link for marketing emails.  The spirit of these
   fields is similar, to make it as easy as possible for a consumer to
   exercise their privacy rights.

Sullivan, et al.        Expires 28 December 2024                [Page 6]
Internet-Draft           Privacy.txt File Format               June 2024

   In this section, a _one-click URL_ refers to a URL that can process a
   request without requiring a customer password or login.  The URL
   should take customer identification such as email and verify as
   necessary to complete the request.

   It is allowed to have multiple conforming Action-* values for the
   same action.

   An API standard to make privacy actions more toolable is not covered
   in this proposal.  This proposal could be extended in the future to
   allow some well-defined API actions given there is at least one other
   non-assisted option available.

1.5.1.  Privacy contact email

   Mandatory, single entry

   Contact: mailto:EMAIL

   An email contact for the privacy office must be given.  This email
   must be able to handle consumer requests via email where there is not
   an applicable Action-* field for the request.  Responses can ask for
   additional verification but should not require customer password or
   login.  If Action-* fields are defined for all applicable consumer
   requests, this email does not need to handle any requests.  This
   proposal imagines companies would build self-service one-click URLs
   for all consumer actions as the most scalable outcome.

1.5.2.  Actions

1.5.2.1.  Account and data deletion

   Optional, single entry

   Action-delete-account-and-data: mailto:EMAIL|URL

   Email or one-click URL to process an account and data deletion
   request.

1.5.2.2.  Personal data deletion

   Optional, single entry

   Action-delete-personal-data: mailto:EMAIL|URL

   Email or one-click URL to process a personal data deletion request.

Sullivan, et al.        Expires 28 December 2024                [Page 7]
Internet-Draft           Privacy.txt File Format               June 2024

1.5.2.3.  Opt out of third-party data sharing

   Optional, single entry

   Action-opt-out-sharing:mailto: EMAIL|URL

   Email or one-click URL to opt out of personal data sharing with third
   parties.

1.5.2.4.  List of third parties

   Optional, single entry

   Action-shared-list:mailto: EMAIL|URL

   Email or one-click URL to get a list of all third parties where
   personal data has been shared.

1.5.2.5.  Opt out of marketing

   Optional, single entry

   Action-opt-out-marketing: mailto:EMAIL|URL

   Email or one-click URL to opt out of marketing.

1.6.  Cookie disclosures

   Common privacy laws call for transparency in cookie storage.  In
   order to audit and enforce transparency, this file format proposes
   fields that describe the cookies used by a web site, following a
   previously published format [GUIDE].  A web browser could technically
   enforce this declaration by refusing access to undeclared cookies.

1.6.1.  Consent banner

   Optional, single entry

   Banner: CONSENT_PRESENT

   A boolean attribute, using 0 or 1 representing false (0) and true
   (1), whether a consent banner is present.

1.6.2.  Consent platform name

   Optional, single entry

   Consent-platform: CONSENT_PLATFORM

Sullivan, et al.        Expires 28 December 2024                [Page 8]
Internet-Draft           Privacy.txt File Format               June 2024

   The consent management platform name, which can be set to non-
   specific-custom or any identifying name if it is a custom banner, or
   set to none detected when there is not banner.

1.6.3.  Cookies

   Optional, multiple entries

   Cookie: 1_NAME, 2_DOMAIN, 3_DURATION, 4_PARTY, 5_OPTIONAL,
   6_HTTPONLY, 7_SECURE

   The field values are given as a complete septuple with each field
   defined by the sections, taken from [GUIDE].  From these fields, the
   most important cookie attributes related to privacy and compliance
   can be derived.

1.6.3.1.  1_NAME Cookie name

   NAME

   The name of the cookie.  This identifies which cookie is set.  The
   website uses this together with the value to identify the cookie.

1.6.3.2.  2_DOMAIN Domain name of the cookie

   URL

   The domain attribute of a cookie specifies which domain may receive
   the cookie.  If this is the same as the host domain, that means it is
   a first party cookie.

1.6.3.3.  3_DURATION Duration of the cookie

   DURATION

   The duration attribute contains the storage limit of the cookie.
   This is in the form of the amount of seconds the cookies will remain
   on the user's device before it is expired and deleted.

1.6.3.4.  4_PARTY First or Third party cookie

   This is a boolean attribute, using 0 or 1 representing false (0) and
   true (1), that indicates whether the cookie is a third party cookie.
   Thus means that the target domain is different from the host domain.
   It is placed on the website by someone other than the owner and
   collects data for that third party.

Sullivan, et al.        Expires 28 December 2024                [Page 9]
Internet-Draft           Privacy.txt File Format               June 2024

1.6.3.5.  5_OPTIONAL Optional status

   This is a boolean attribute, using 0 or 1 representing false (0) and
   true (1), which indicates whether this is an options cookie or not.
   Optional cookies can be refused by the user, using the consent
   banner.  When cookies are not optional they will always be placed on
   the user's device when they access the website, with or without
   consent.

1.6.3.6.  6_HTTPONLY HTTPonly status

   This is a boolean attribute, using 0 or 1 representing false (0) and
   true (1), which indicates whether the httpOnly flag is set.  This
   means that the cookie can only be transferred via HTTP, and therefor
   the cookie can only be accessed by the current server.  This helps
   mitigate clientside scripts accessing the cookie data.

1.6.3.7.  7_SECURE Secure status

   This is a boolean attribute, using 0 or 1 representing false (0) and
   true (1), which indicates whether the secure flag is set on the
   cookie.  The secure flag causes the browser to only send the cookie
   over encrypted channels, therefor securing the communication between
   the user's device and the server.

2.  Other records

   Other records that are not part of the privacy.txt protocol may be
   included.  For example, a regulation-specific record like action-
   fcra-freeze could be added to comply to FCRA obligations.

3.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

4.  Security Considerations

   Following this file format makes it easier for consumers to take
   privacy actions, similar to one-click unsubscribe.  Removing the
   barrier to actions makes it easier to make mistakes.  It would be
   reasonable to allow some grace period of undo in case of a security
   incident.

Sullivan, et al.        Expires 28 December 2024               [Page 10]
Internet-Draft           Privacy.txt File Format               June 2024

5.  IANA Considerations

   This document has no IANA actions.

6.  References

6.1.  Normative References

   [ISO3166]  International Organization for Standardization (ISO),
              "Codes for the representation of names of countries and
              their subdivisions - Part 1: Country codes", 2020,
              <https://www.iso.org/standard/72482.html>.

   [ISO639]   International Organization for Standardization (ISO),
              "Code for individual languages and language groups", 2023,
              <https://www.iso.org/standard/74575.html>.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              DOI 10.17487/RFC2046, November 1996,
              <https://www.rfc-editor.org/rfc/rfc2046>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/rfc/rfc3629>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/rfc/rfc3986>.

   [RFC6068]  Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
              URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
              <https://www.rfc-editor.org/rfc/rfc6068>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <https://www.rfc-editor.org/rfc/rfc7230>.

Sullivan, et al.        Expires 28 December 2024               [Page 11]
Internet-Draft           Privacy.txt File Format               June 2024

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <https://www.rfc-editor.org/rfc/rfc7231>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/rfc/rfc8615>.

6.2.  Informative References

   [ADS-TXT]  IAB Tech Lab, "Ads.txt 1.1 Specification", April 2022,
              <https://iabtechlab.com/wp-content/uploads/2022/04/
              Ads.txt-1.1.pdf>.

   [CAN-SPAM] Federal Communications Commission (FCC), "CAN-SPAM Act: A
              Compliance Guide for Business", n.d.,
              <https://www.fcc.gov/general/can-spam>.

   [GUIDE]    Peet, L. V. D., "Increasing privacy-related transparency
              on the web using a self-disclosing standard", 2023,
              <http://resolver.tudelft.nl/uuid:64b40236-787d-
              4ae0-8700-60cfe1598bfe>.

   [MANAGERS] "Consent Manager List", n.d., <https://github.com/privacy-
              txt/privacy-txt-tools/blob/master/data-collector/data/
              consent_managers.json>.

   [RFC9116]  Foudil, E. and Y. Shafranovich, "A File Format to Aid in
              Security Vulnerability Disclosure", RFC 9116,
              DOI 10.17487/RFC9116, April 2022,
              <https://www.rfc-editor.org/rfc/rfc9116>.

   [RFC9309]  Koster, M., Illyes, G., Zeller, H., and L. Sassman,
              "Robots Exclusion Protocol", RFC 9309,
              DOI 10.17487/RFC9309, September 2022,
              <https://www.rfc-editor.org/rfc/rfc9309>.

Acknowledgments

Authors' Addresses

   Nick Sullivan
   Cryptography Consulting LLC

Sullivan, et al.        Expires 28 December 2024               [Page 12]
Internet-Draft           Privacy.txt File Format               June 2024

   Email: nicholas.sullivan+ietf@gmail.com

   Louise Van Der Peet
   TU Delft
   Email: L.VanderPeet@tudelft.nl

   Georgios Smaragdakis
   TU Delft
   Email: g.smaragdakis@tudelft.nl

   Brien Colwell
   BringYour, Inc.
   Email: brien@bringyour.com

Sullivan, et al.        Expires 28 December 2024               [Page 13]