A File Format to Aid in Consumer Privacy Enforcement, Research, and Tools
draft-colwell-privacy-txt-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Nick Sullivan , Louise Van der Peet , Georgios Smaragdakis , Brien Colwell | ||
| Last updated | 2024-04-15 | ||
| RFC stream | (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-00
Network Working Group N. Sullivan
Internet-Draft
Intended status: Informational L. V. D. Peet
Expires: 17 October 2024 G. Smaragdakis
TU Delft
B. Colwell
BringYour, Inc.
15 April 2024
A File Format to Aid in Consumer Privacy Enforcement, Research, and
Tools
draft-colwell-privacy-txt-00
Abstract
This proposal outlines a new file format called privacy.txt. It
follows similar placement on a web server as robots.txt
// https://datatracker.ietf.org/doc/html/rfc9309, security.txt
// https://datatracker.ietf.org/doc/html/rfc9116, or ads.txt
// https://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
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://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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Sullivan, et al. Expires 17 October 2024 [Page 1]
Internet-Draft Privacy.txt File Format April 2024
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 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. 1. A machine parsable and complete privacy policy . . . 3
1.2. 2. Consumer actions under their privacy rights . . . . . 4
1.3. 3. Cookie disclosures . . . . . . . . . . . . . . . . . 5
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Normative References . . . . . . . . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
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.
Sullivan, et al. Expires 17 October 2024 [Page 2]
Internet-Draft Privacy.txt File Format April 2024
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.txt
// https://datatracker.ietf.org/doc/html/rfc9309, security.txt
// https://datatracker.ietf.org/doc/html/rfc9116, or ads.txt
// https://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.
1.1. 1. 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.
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
Sullivan, et al. Expires 17 October 2024 [Page 3]
Internet-Draft Privacy.txt File Format April 2024
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.
1.2. 2. 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
// https://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
Sullivan, et al. Expires 17 October 2024 [Page 4]
Internet-Draft Privacy.txt File Format April 2024
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.
1.3. 3. 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
// privacy.txt Implementation Guide Louise van der Peet November
2022. A web browser could technically enforce this declaration by
refusing access to undeclared cookies.
Banner: CONSENT_PRESENT,CONSENT_PLATFORM
A boolean attribute whether a consent banner is present, and 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.
Cookie: FIELD#1,FIELD#2,...FIELD#7
The field values are given as a complete septuple with each field
defined by the following table, taken from
// privacy.txt Implementation Guide Louise van der Peet November
2022. From these fields, the most important cookie attributes
related to privacy and compliance can be derived.
+=========+==========+==============================================+
| Field | Name | Description |
+=========+==========+==============================================+
| FIELD#1 | Cookie | The name of the cookie. This |
| | name | identifies which cookie is set. The |
| | | website uses this together with the |
| | | value to identify the cookie. |
Sullivan, et al. Expires 17 October 2024 [Page 5]
Internet-Draft Privacy.txt File Format April 2024
+---------+----------+----------------------------------------------+
| FIELD#2 | Domain | The domain attribute of a cookie |
| | name of | specifies which domain may receive the |
| | the | cookie. If this is the same as the |
| | cookie | host domain, that means it is a first |
| | | party cookie. |
+---------+----------+----------------------------------------------+
| FIELD#3 | Duration | The duration attribute contains the |
| | of the | storage limit of the cookie. This is |
| | cookie | in the form of the amount of seconds |
| | | the cookies will remain on the user’s |
| | | device before it is expired and |
| | | deleted. |
+---------+----------+----------------------------------------------+
| FIELD#4 | First or | This is a boolean attribute that |
| | Third | indicates whether the cookie is a third |
| | party | party cookie. Thus means that the |
| | cookie | target do- main 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. |
+---------+----------+----------------------------------------------+
| FIELD#5 | Optional | This is a boolean attribute which |
| | cookie | 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. |
+---------+----------+----------------------------------------------+
| FIELD#6 | Httponly | This is a boolean attribute 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 cur- rent server. This |
| | | helps mitigate client- side scripts |
| | | accessing the cookie data. |
+---------+----------+----------------------------------------------+
| FIELD#7 | Secure | This is a boolean attribute which |
| | status | 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 de- vice and the |
| | | server. |
Sullivan, et al. Expires 17 October 2024 [Page 6]
Internet-Draft Privacy.txt File Format April 2024
+---------+----------+----------------------------------------------+
Table 1
2. 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.
3. 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.
4. IANA Considerations
This document has no IANA actions.
5. Normative References
[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>.
[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>.
Acknowledgments
Authors' Addresses
Nick Sullivan
Email: nicholas.sullivan+ietf@gmail.com
Louise Van der Peet
TU Delft
Email: L.VanderPeet@tudelft.nl
Sullivan, et al. Expires 17 October 2024 [Page 7]
Internet-Draft Privacy.txt File Format April 2024
Georgios Smaragdakis
TU Delft
Email: g.smaragdakis@tudelft.nl
Brien Colwell
BringYour, Inc.
Email: brien@bringyour.com
Sullivan, et al. Expires 17 October 2024 [Page 8]