A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Meta referrer: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
No edit summary
 
(16 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{obsolete|spec=[http://w3c.github.io/webappsec/specs/referrer-policy/ Referrer Policy]}}
==Overview==
==Overview==


Line 20: Line 22:


A blog hosted over HTTPS might wish to link to a blog hosted over HTTP and receive [http://en.wikipedia.org/wiki/Trackback trackback] links.
A blog hosted over HTTPS might wish to link to a blog hosted over HTTP and receive [http://en.wikipedia.org/wiki/Trackback trackback] links.
===Object-Capability Discipline===
Some web applications wish to follow an object-capability discipline.  The <code>Referer</code> header constitutes an ambient authority, contrary to an object-capability discipline.  Having the ability to disable the <code>Referer</code> header makes it easier for these web applications to follow this discipline.


==Specification==
==Specification==
===Syntax===


Keyword: <code>referrer</code>
Keyword: <code>referrer</code>


The referrer metadata attribute can have one of four values:
The referrer metadata attribute can have one of four values for its content attribute:
* <code>never</code>
* <code>never</code>
* <code>always</code>
* <code>always</code>
Line 33: Line 37:
* <code>default</code>
* <code>default</code>


Let ''referrer-policy'' be the value of the <code>content</code> attribute with <code>LWS</code> stripped from the beginning and end of the string and converted to lower case. If ''referrer-policy'' is none of the strings listed above, the user agent MUST act as if ''referrer-policy'' is the string <code>default</code>.
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:
# If the meta element lacks a content attribute, abort these steps.
# Let the document's ''referrer-policy'' be the value of the content attribute converted to lower case with leading and trailing <code>LWS</code> removed.
# If the document's ''referrer-policy'' is not one of the strings listed above, replace the document's ''referrer-policy'' with the string <code>default</code>.


===Semantics===
''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:
Replace Step 3 of ''Fetching resources'' in the HTML standard [[http://www.whatwg.org/specs/web-apps/current-work/ HTML]] with the following text:
<blockquote>
<blockquote>
Let the ''referrer-header-value'' be the document's ''current address of document''.
Let the ''referrer-header-value'' be the document's ''current address of document''.
Line 52: Line 59:


* If the ''referrer-policy'' is <code>origin</code>:
* If the ''referrer-policy'' is <code>origin</code>:
: Replace the ''referrer-header-value'' with the ''ASCII serialization'' [ORIGIN] of the ''origin' of the appropriate Document.
: Replace the ''referrer-header-value'' with the ''ASCII serialization'' [[http://tools.ietf.org/html/draft-ietf-websec-origin ORIGIN]] of the ''origin' of the appropriate Document.


* If the ''referrer-policy'' is <code>always</code>:
* If the ''referrer-policy'' is <code>always</code>:
: Do not alter the ''referrer-header-value''.  '''Warning! This might cause https referrers to be sent over the network as part of unencrypted HTTP requests.'''
: 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.'''
</blockquote>
</blockquote>


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:
 
''Question:'' Do we need a <code>always-origin</code> 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 [[http://www.whatwg.org/specs/web-apps/current-work/ HTML]], replace the text "For the purposes of the Referer (sic) header, [...]" with the following text:
<blockquote>
<blockquote>
For the purposes of the Referer (sic) header, use the ''referrer-header-value'' are generated in Step 3.
For the purposes of the Referer (sic) header, use the ''referrer-header-value'' are generated in Step 3.
</blockquote>
</blockquote>
''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==
==Examples==
Line 74: Line 87:
<meta name="referrer" content="origin">
<meta name="referrer" content="origin">
</pre>
</pre>
'''Note:''' The user agent will include the origin string in the <code>Referer</code> 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.


[[Category:Proposals]]
[[Category:Proposals]]

Latest revision as of 14:32, 7 October 2014

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.