Policy Discovery

1. Introduction

This section is non-normative.

Websites' privacy policies and terms of service are important documents, describing the ways in which data that flows through the site can be used, managed, shared, combined with other data sources; and the agreements under which the website offers its services. The precise definition and impact of these policy documents will vary based on a number of factors, but it seems clear that whatever the exact contours of the legal framework in which it exists, they represents a set of promises that the site’s users ought to be able to rely upon. It’s therefore important for users to be able to easily discover, read through, and rely upon them interacting with a site.

Recognizing this, many sites will place a prominent link to their policies in a place where they believe users might look for it: the site’s footer, for example. This document suggests two improvements to discoverability which may help user agents and other tools make policy documents more accessible to users (perhaps by exposing links to a site’s policies in prominent places in the user agent’s UI):

1. § 2 Well-Known URLs defines the /.well-known/privacy-policy and /.well-known/terms-of-service well-known URIs [RFC8615].

2. § 3 Link Types defines the privacy-policy and terms-of-service link types, which can be used to annotate a and link elements that reference the policies that apply to a given document (and area too, I suppose... why not?).

2. Well-Known URLs

2.1. The privacy-policy Well-Known URL

An origin’s privacy policy URL is a URL that directly identifies the origin’s privacy policy resource. An origin’s well-known privacy policy URL is a URL whose path component is /.well-known/privacy-policy. Responses to requests for this resource should redirect to the privacy policy URL, thereby facilitating its automated discovery.

Given an origin (origin), a client can construct a well-known privacy policy URL by running the following steps:

1. If origin is not a potentially trustworthy origin, return failure.

   Note: Origins which are not delivered securely can make no meaningful promises about the privacy of data flowing to and from the client, as the communication channel is plaintext and available to (and manipulatable by) anyone on the network between the client and the server.

2. Assert: origin is a tuple origin.

3. Let url be a new URL with values set as follows:

   • scheme: origin’s scheme.

   • host: origin’s host.

   • port: origin’s port.

   • path: « ".well-known", "privacy-policy" »

4. Return url.

2.2. The terms-of-service Well-Known URL

An origin’s terms of service URL is a URL that directly identifies the origin’s terms of service resource. An origin’s well-known terms of service URL is a URL whose path component is /.well-known/terms-of-service. Responses to requests for this resource should redirect to the terms of service URL, thereby facilitating its automated discovery.

Given an origin (origin), a client can construct a well-known terms of service URL by running the following steps:

1. If origin is not a potentially trustworthy origin, return failure.

   Note: Origins which are not delivered securely can make no meaningful promises about the privacy of data flowing to and from the client, as the communication channel is plaintext and available to (and manipulatable by) anyone on the network between the client and the server.

2. Assert: origin is a tuple origin.

3. Let url be a new URL with values set as follows:

   • scheme: origin’s scheme.

   • host: origin’s host.

   • port: origin’s port.

   • path: « ".well-known", "terms-of-service" »

4. Return url.

2.3. Server Considerations

Servers complying with this document’s recommendations SHOULD respond to requests for an origin’s well-known privacy policy URL and well-known terms of service URL with a response whose status is one of « 302, 303, 307 », and which contains a Location header whose value is the origin’s privacy policy URL or terms of service URL, respectively.

Servers MAY also return a Location header whose value is a URL that, in turn, redirects to the requested resource.

Note: The status codes here support only temporary redirects. As discussed in w3c/webappsec-change-password-url#13, this intentionally excludes permanent redirect codes in order to ensure that intermediate caches and client applications continue to check the well-known URL to catch changes in a site’s structure.

An origin’s privacy policy URL does not need to live on that origin. Clients should support https://example.com’s policy documents being hosted by https://policies.example.com/ or https://holding-company.example/, for example.

HTTP/1.1 307 Temporary Redirect
...
Location: https://example.com/privacy

2.4. Client Considerations

Given the potentially-cross-origin nature of these requests, clients making automated requests for these well-known URLs are encouraged to do so with the request’s credentials mode set to omit and its referrer set to no-referrer.

3. Link Types

Note: The following two sections define the privacy-policy and terms-of-service link types. If standardized, these should eventually migrate to HTML’s list of link types.

3.1. The privacy-policy Link Type

Sites are encouraged to place links to their privacy policy in conspicuous places where users might look for them. To improve discoverability, this document defines the privacy-policy link type as an annotation for a and link elements, enhancing their semantic meaning in a way user agents can understand and make available to users.

<a rel="privacy-policy" href="https://example.com/privacy">Privacy Policy</a>

<link rel="privacy-policy" href="https://example.com/privacy">

This extension to HTML’s set of link types has the following properties:

Link Type

privacy-policy

Effect on link

Hyperlink

Effect on a, area

Hyperlink

Effect on form

Not allowed

body-ok

Yes

Has link processing

No

Brief Description

Refers to a document which contains information about the data collection and usage practices that apply to the current context. This may be a standalone privacy policy, or a specific section of some more general document.

-- This query is an undercount (insofar as it doesn’t account for
-- multiple link types), but likely in the right order of magnitude.
SELECT
  COUNTIF(REGEXP_CONTAINS(LOWER(body), r"rel=(privacy[ >]|\'privacy\'|\"privacy\")")) as privacy,
  COUNTIF(REGEXP_CONTAINS(LOWER(body), r"rel=(privacy-policy|\'privacy-policy\'|\"privacy-policy\")")) as privacy_policy
FROM
  \`httparchive.response_bodies.2023_08_01_desktop\`
WHERE
  page = url

3.2. The terms-of-service Link Type

Sites are encouraged to place links to their terms of service in conspicuous places where users might look for them. To improve discoverability, this document defines the terms-of-service link type as an annotation for a and link elements, enhancing their semantic meaning in a way user agents can understand and make available to users.

<a rel="terms-of-service" href="https://example.com/tos">Terms of Service</a>

<link rel="terms-of-service" href="https://example.com/tos">

This extension to HTML’s set of link types has the following properties:

Link Type

terms-of-service

Effect on link

Hyperlink

Effect on a, area

Hyperlink

Effect on form

Not allowed

body-ok

Yes

Has link processing

No

Brief Description

Refers to a document which contains information about the agreements between a service provider and users who wish to use the service provided.

Note: HTTP Archive didn’t give much guidance with regard to naming. The most popular rel attribute value that contained the word "terms" was rel="terms of service", which unfortunately isn’t an appropriate link type. This document is running with terms-of-service, though other names could certainly be reasonable (terms-and-conditions, tos, etc).

4. Implementation Considerations

This section is non-normative.

4.1. Scope

The well-known URLs defined in this document provide a mechanism through which one and only one document can be declared as binding for the entirety of an origin. This is reasonable, as that’s the only security boundary that the web offers: data flowing to one page on an origin is accessible to other pages on the origin, as is storage, and potential server-side interrelations between pages are opaque to the user. Site operators are encouraged to make such global policy documents available.

It’s important to note, however, that websites might host policies for applications that run outside the context of the web platform. https://amazing-mobile-app.example might offer a website alongside native apps on multiple platforms with differing data collection and usage characteristics. In this case, clients should expect the well-known URLs to represent only the policies that applies to the web origin.

Note: It would be possible to extend this proposal with specific well-known links for policies on a platform-by-platform basis (e.g. /.well-known/privacy-policy/Windows, /.well-known/privacy-policy?platform=iOS, or some other spelling). It’s not clear whether that addition is worthwhile, but it would be fairly straightforward to define by adding a platform parameter to the construct a well-known privacy policy URL and construct a well-known terms of service URL algorithm.

4.2. Relation to P3P

The [P3P] specification defines a machine-readable representation of a site’s privacy practices, and it’s reasonable to wonder whether this proposal is in some way related. It is not: this proposal is substantially narrower, suggesting only that it should be trivial to discover the URL at which origin’s existing privacy policy prose resides.

5. IANA Considerations

This document defines the privacy-policy and terms-of-service well-known URIs. These will be submitted to the IESG for review, approval, and registration with IANA using the template defined in [RFC8615] as follows:

URI Suffix

privacy-policy

Change Controller

W3C, possibly?

Specification Document

The § 2.1 The privacy-policy Well-Known URL section of this document.

Related Information:

None.

And:

URI Suffix

terms-of-service

Change Controller

W3C, possibly?

Specification Document

The § 2.2 The terms-of-service Well-Known URL section of this document.

Related Information:

None.

6. Acknowledgements

This document borrowed structure and content liberally from Ricky Mondello and Theresa O’Connor’s [change-password-url].