Meta referrer

This document is obsolete.

For the current specification, see: Referrer Policy

Overview

This document describes a proposal the "referrer" metadata name. Using the referrer metadata attribute, a document can control the behavior if the Referer HTTP header attached to requests that originate from the document.

Use Cases

An author might wish to control the Referer header omitted by a document for a number of reasons.

Privacy

A social networking site has a profile page for each of its users, and users add hyperlinks from their profile page to their favorite bands. The social networking site might not wish to leak the user's profile URL to the band web sites when other users follow those hyperlinks (because the profile URLs might reveal the identity of the owner of the profile).

Some social networking sites, however, might wish to inform the band web sites that the links originated from the social networking site but not reveal which specific user's profile contained the links.

Security

A web application uses HTTPS and a URL-based session identifier. The web application might wish to link to HTTPS resources on other web sites without leaking the user's session identifier in the URL.

Trackback

A blog hosted over HTTPS might wish to link to a blog hosted over HTTP and receive trackback links.

Object-Capability Discipline

Some web applications wish to follow an object-capability discipline. The Referer header constitutes an ambient authority, contrary to an object-capability discipline. Having the ability to disable the Referer header makes it easier for these web applications to follow this discipline.

Specification

Keyword: referrer

The referrer metadata attribute can have one of four values for its content attribute:

• never
• always
• origin
• default

When a meta element is inserted into the document, if its name attribute is presents and matches the referrer metadata name, then the user agent must run the following algorithm:

1. If the meta element lacks a content attribute, abort these steps.
2. Let the document's referrer-policy be the value of the content attribute converted to lower case with leading and trailing LWS removed.
3. If the document's referrer-policy is not one of the strings listed above, replace the document's referrer-policy with the string default.

TODO: This algorithm causes the most recently added meta element to control the referrer-policy. Should we support changing the policy by setting the content attribute?

Replace Step 3 of Fetching resources in the HTML standard [HTML] with the following text:

Let the referrer-header-value be the document's current address of document.

Remove any <fragment> component from the referrer-header-value.

If the origin of the appropriate Document is not a scheme/host/port tuple, then replace the referrer-header-value with the empty string, regardless of its value.

• If the referrer-policy is never:

Replace the referrer-header-value with the empty string, regardless of its value.

• If the referrer-policy is default:

Replace the referrer-header-value with the empty string if the <scheme> component of the referrer-header-value represents a protocol that uses transport-layer security and the <scheme> component of the resource being fetched does not.

• If the referrer-policy is origin:

Replace the referrer-header-value with the ASCII serialization [ORIGIN] of the origin' of the appropriate Document.

• If the referrer-policy is always:

Do not alter the referrer-header-value. Note: This might cause https referrers to be sent over the network as part of unencrypted HTTP requests.

Question: Do we need a always-origin value as well? As to permit websites to use the always policy while still just sending the origin? For example to enable https websites to send an origin to http websites.

In Step 5 of Fetching resources in the HTML standard [HTML], replace the text "For the purposes of the Referer (sic) header, [...]" with the following text:

For the purposes of the Referer (sic) header, use the referrer-header-value are generated in Step 3.

TODO: We want this policy to affect resource loads done by the speculative parser. I'm not sure the speculative parser is part of the spec's machinery, so we need to figure out how to specify its behavior... Perhaps in an implementation consideration section?

Examples

This meta element instructs the user agent to omit the Referer header in all HTTP requests that originate from the document containing the element:

<meta name="referrer" content="never">

This meta element instructs the user agent to include the document's origin in the Referer header rather than the full URL of the document:

<meta name="referrer" content="origin">

Note: The user agent will include the origin string in the Referer header even for links from HTTPS to HTTP resources.

Issues

How does this interact with rel=noreferrer? Presumably rel=noreferrer should override whatever global setting the user agent gets from the meta element.

The origin is not a canonical URL as it lacks a path. The user agent should probably just add / as path.

What should happen if the origin is unique? Presumably the referrer should be omitted in that case.