| Internet-Draft | Privacy.txt File Format | April 2024 |
| Sullivan, et al. | Expires 17 October 2024 | [Page] |
This proposal outlines a new file format called privacy.txt. It follows similar placement on a web server as robots.txthttps://datatracker.ietf.org/doc/html/rfc9309, security.txthttps://datatracker.ietf.org/doc/html/rfc9116, or ads.txthttps://iabtechlab.com/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¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://example.com/LATEST. 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 WG Working Group mailing list (mailto:WG@example.com), which is archived at https://example.com/WG.¶
Source for this draft and an issue tracker can be found at https://github.com/USER/REPO.¶
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 17 October 2024.¶
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.¶
Consumers in many parts of the world have extensive privacy rights under laws such as the GDPR and the CPRA. 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. It follows similar placement on a web server as robots.txthttps://datatracker.ietf.org/doc/html/rfc9309, security.txthttps://datatracker.ietf.org/doc/html/rfc9116, or ads.txthttps://iabtechlab.com/ads-txt/, in the / directory or /.well-known directory [1,2,3].¶
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¶
The file format is UTF8 text and lists Field:Value, one per line. Whitespace and lines that start with # are ignored.¶
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.¶
Entity: NAME,COUNTRY_CODE¶
The entity issuing the privacy policy. A name that contains a comma should escape the comma as \,. The country code should follow 2-letter ISO 3166-1.¶
Privacy-policy-text: URL¶
A complete privacy policy in a single UTF8 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.¶
Privacy-policy: 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.¶
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 Acthttps://www.fcc.gov/general/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.¶
Below 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.¶
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.¶
Action-delete-account-and-data: mailto:EMAIL|URL¶
Email or one-click URL to process an account and data deletion request.¶
Action-delete-personal-data: mailto:EMAIL|URL¶
Email or one-click URL to process a personal data deletion request.¶
Action-opt-out-sharing:mailto: EMAIL|URL¶
Email or one-click URL to opt out of personal data sharing with third parties.¶
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.¶
Action-opt-out-marketing: mailto:EMAIL|URL¶
Email or one-click URL to opt out of marketing.¶
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.¶
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.¶
This document has no IANA actions.¶