Referer (sic)

One of the more astonishing facets of the web platform is the Referer header.  Whenever you click a link from one web site to another, the request that fetches the web page from the second web site contains the URL of the first web site.  This behavior causes both security and privacy problems:

1. Security.  Despite copious warnings, developers often include secrets in URLs.  For example, to prevent Cross-Site Request Forgery (CSRF), developers often use secret tokens, which have a nasty habit of leaking into URLs and then into Referer headers sent to other sites.
2. Privacy.  The Referer header is even worse for privacy, for example, leaking search terms from your favorite search engine to the web sites you visit.  As another example, Facebook accidentally leaked user identities to advertisers via the Referer header.

The principle of least astonishment tells us we should remove this "feature", but, unfortunately, we can't just remove the Referer header from the platform.  To many people rely on the Referer header for too many different purposes.  For example, bloggers rely on the Referer header to generate trackback links, but that's just the tip of the iceberg.

As a first step, I wrote up a short proposal for a mechanism web sites can use to suppress or truncate the Referer header:

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

One subtlety in the design is including the "always" option.  The main reason to include this option is to make it easier for us to later block the Referer header by default.  The always options gives sites an escape valve to turn the Referer header back on, if needed.

This mechanism is now implemented in WebKit and will hopefully be implemented in Firefox and other browsers soon.