Define the privacy-policy link type.

[mikewest]

This PR defines a privacy-policy link type that refers to a document which
contains information about the data collection and usage practices that apply
to the current context.

This link type was defined in section 4 of RFC6903, and rediscovered in
a discussion at privacycg/proposals#39.

---

I'm submitting this as a PR, as there appears to be a reasonable amount of interest in the privacy-policy link type from the PrivacyCG discussion linked above. I haven't sent a similar PR for terms-of-service as it's not actually clear to me whether jumping straight to HTML is justified. So, I figured I'd ask in the form of a PR. :)

• At least two implementers are interested (and none opposed):
  • Chromium (at least Chrome (👋)and Brave (@kdenhartog in this comment)).
  • Gecko (@bvandersloot-mozilla's last comment is supportive of the link type)
• Tests are unnecessary(?), as I don't think there's any web-facing mechanism of determining which link types a given user agent supports, nor is there any web-facing result of defining such a link type that's expected. See also @domenic's comment below regarding rel's supported tokens.
• Implementation bugs are unnecessary for the same reason.
• MDN issue is filed: Describe two new rel link types. mdn/content#29801
• The top of this comment includes a clear commit message to use.

---

/index.html ( diff )
/links.html ( diff )
/references.html ( diff )

[kdenhartog]

LGTM,

Also expressing support here for a terms of service link that matches this behavior.

[annevk]

Would this be in addition to or instead of the .well-known scheme?

[mikewest]

I think both are valuable, and would like both to be a thing. Would you suggest defining both in HTML? I was assuming any .well-known URL we could agree on would be a separate document.

[domenic]

A few wording tweaks.

We need to decide whether this impacts

rel's supported tokens are the keywords defined in HTML link types which are allowed on a and area elements, impact the processing model, and are supported by the user agent. The possible supported tokens are noreferrer, noopener, and opener. rel's supported tokens must only include the tokens from this list that the user agent implements the processing model for.

It's somewhat vague what "implements the processing model" means; if the browser provides some sort of UI for showing the current page's privacy policy, is that a "processing model"? I'd lean toward no; we currently don't include next / prev in this way, although in theory they could generate similar browser UI.

So I think no changes to supported tokens are needed. But I wanted to make sure others agreed first.

[mikewest]

A few wording tweaks.

Accepted, thanks.

It's somewhat vague what "implements the processing model" means; if the browser provides some sort of UI for showing the current page's privacy policy, is that a "processing model"? I'd lean toward no; we currently don't include next / prev in this way, although in theory they could generate similar browser UI.

So I think no changes to supported tokens are needed. But I wanted to make sure others agreed first.

I agree with this reasoning. Given the lack of web-facing behavior, I don't think it makes sense to change the supported token set.

[annevk]

As some colleagues and I are still discussing this I removed WebKit as interested party for now. It's also not clear to me that @bvandersloot-mozilla is fully on board given his stated preferences in the linked issue. So overall I'd prefer we wait a bit until there's more clarity.

[bvandersloot-mozilla]

I'm on board with this change. My concern is with the .well-known resource, which is not included here.

[mikewest]

As some colleagues and I are still discussing this I removed WebKit as interested party for now.

If it would be useful to provide any additional feedback into that discussion, I'd be happy to.

[othermaciej]

Given that the privacy policy is supposed to be site-wide, why are both rel and the .well-known mechanism proposed? It seems like .well-known is sufficient for a policy that is required to be site-wide, and the existence of the rel in addition creates the possibility for error (choosing different places for different pages, or a policy inconsistent with what .well-known points to), and then confusion for anything trying to do machine processing of these values (which should take precedence if they differ?)

This is not the world's strongest objection b/c this link type doesn't seem super useful to browsers, but it's not apparent what benefits there are to having both mechanisms that outweigh the downsides.

[npdoty]

Should this cite RFC 6903, which (also) defines a privacy-policy link relation?

(Mostly I'm just happy that we didn't choose an inconsistent value.)

[domenic]

Should this cite RFC 6903, which (also) defines a privacy-policy link relation?

Oh, very interesting.

HTML defines all the allowed values for rel="" on the <link> element. (Despite what RFC 6903 seems to be doing with its example code.) HTML also defines all Link header processing in web browsers---and indeed, for privacy-policy, there is none.

It looks like we have at least one precedent case where such "informational" Link headers match an allowed <link> rel="" value: https://html.spec.whatwg.org/#link-type-canonical . Probably we should follow that example? Maybe with an explicit note that this can also be delivered via Link header, too.

[mikewest]

Thanks for the comments, @othermaciej, and apologies for my delayed response. I was unexpectedly out at the end of last week.

Given that the privacy policy is supposed to be site-wide, why are both rel and the .well-known mechanism proposed?

At a high level, I'd like the privacy policy that applies to an origin to be more easily discoverable than it is today, both by humans and mechanically. Hopefully that's a small goal we can share. :)

rel="privacy-policy" is somewhat widely used today to annotate links to privacy policies. That seems like a practice we should encourage: it's a trivial semantic enrichment of existing links, and could support some browser/extension/whatever UX that users could peruse without requiring additional, speculative HTTP requests. These annotations are straightforward to add, easy to parse, and meaningful in context.

.well-known/privacy-policy is new, and seems to me valuable as a mechanism of standardizing the declaration of the policies that apply to a given origin, regardless of that origin's ability to serve user-facing HTML. I've also heard anecdotal evidence that there would be a small-but-noticeable performance win for crawlers if they could discover privacy policies as the result of a HEAD request rather than rendering a homepage, JavaScript and all.

the existence of the rel in addition creates the possibility for error (choosing different places for different pages, or a policy inconsistent with what .well-known points to), and then confusion for anything trying to do machine processing of these values (which should take precedence if they differ?)

I think you're right that some origins will be misconfigured in exactly this way. I don't think that's unique to this proposal, however: it's entirely plausible that status-quo websites are pointing to different privacy policies on different pages, using the same text in both places (e.g. <a href="/new-policy">Privacy Policy</a> on one page, <a href="/old-policy">Privacy Policy</a> on another). It's likewise possible that a single page contains distinct links (one in the page's text that hasn't been touched in decades, another in a centrally-configured footer that's well-maintained). Both humans and tooling will already need to deal with these scenarios one way or another.

I'd suggest that these misconfigurations should be treated as a policy problem whose risk we can mitigate at that layer by defining expectations around this mechanism more clearly, creating tooling that points out these errors (e.g. Lighthouse, Web Inspector, etc), and relying on various actors in the ecosystem to help us create incentives for correct usage.

---

With the above in mind, I'd suggest two things:

1. Websites are going to visibly link to their privacy policies, regardless of whether we merge this PR. :) My opinion is that we should incorporate the privacy-policy link type into HTML as a way of paving this particular cowpath. I think there's support for that in this thread and Privacy policy discovery. privacycg/proposals#39 (especially in light of the RFC Nick pointed out).

2. We should not require origins to render HTML in order to declare the policies that they adhere to. We should also define the well-known URL as a pattern that origins ought to adopt to support that use cases, and to explicitly define scoping and specificity considerations. I'm fine with doing that in a separate document or as part of HTML if that's what folks would prefer, but I do see it as being valuable in addition to the link type.

[mikewest]

Hey folks, what are the next steps here? Can we merge it and #9877 (modulo any necessary cleanup), or are there objections to doing so?

[domenic]

I think this is ready to merge, but only because I've been following the discussion closely and spotted #9860 (comment), which is a pretty clear statement of support from a second implementer. It'd be good if the OP was updated to check all the boxes, with citations.

[mikewest]

Done and done. Thanks for your input, @domenic!