
Where did all the HTTP referrers go? (2013) - bemmu
http://smerity.com/articles/2013/where_did_all_the_http_referrers_go.html
======
Smerity
As the author, this was a pleasant surprise! :) It was written in 2013
(potentially note that in the title?) though people still frequently say they
find it useful.

As @jstayton noted, browser support has come a long way[1], and @davecardwell
notes that some of the keywords are deprecated[2]. I really should update both
browser support and the "which websites use it" part. Hacker News now supports
it for example, which I'm hugely glad to see! ^_^

Previous HN discussion:
[https://news.ycombinator.com/item?id=5778444](https://news.ycombinator.com/item?id=5778444)

[1]: [http://caniuse.com/#feat=referrer-
policy](http://caniuse.com/#feat=referrer-policy)

[2]: [https://www.w3.org/TR/referrer-policy/#referrer-policy-
state...](https://www.w3.org/TR/referrer-policy/#referrer-policy-states)

~~~
pbreit
I didn't see this explicitly mentioned but if my site is HTTPS, I get
referers, right? And so isn't that the easiest/best solution?

~~~
Smerity
From the article:

> HTTPS websites will send referrers to any other HTTPS website even if it
> contains sensitive information

As such, having a website which is HTTPS will get you referers from both HTTP
and HTTPS if they're willing to send them, but it's also important to know you
can control them in case there are privacy implications such as leaking your
customer's information to external HTTPS sites.

~~~
sopooneo
Thank you for this, because I think I'm about to learn from you, but I'm
confused. How can you control them? Is there some way for a site to signal to
a browser whether it should or send referrer headers and under what
circumstances?

~~~
Smerity
The site can signal, either via server headers or meta tags, whether to send
or withhold referrers.

Adding <meta name="referrer" content="never"> will prevent referrers from
being sent, whilst <meta name="referrer" content="always"> will ensure they're
sent whether linking to HTTP or HTTPS.

The user can of course override these if so desired - see the extensions
linked to by many other commenters.

------
davecardwell
_Note: Authors are encouraged to avoid the legacy keywords never, default, and
always. The keywords none, none-when-downgrade, and unsafe-url respectively
are preferred._

\- [https://www.w3.org/TR/referrer-policy/#referrer-policy-
deliv...](https://www.w3.org/TR/referrer-policy/#referrer-policy-delivery-
meta)

Although the current versions of Edge only support the legacy keywords
according to [http://caniuse.com/#feat=referrer-
policy](http://caniuse.com/#feat=referrer-policy)

~~~
tempestn
Do you happen to know what Edge defaults to if it doesn't recognize the value?
One would hope to "never"?

~~~
davecardwell
I don’t know, sorry, although I would suspect they stick to “default”.

~~~
tempestn
Just tested this myself and it looks like you're right. With meta referrer set
to content=never, Edge passes the referrer. With content=none it doesn't.
Chrome is the opposite, and Firefox does not send the referrer in either case.
(And of course IE sends it in both cases, since it doesn't recognize the
referrer meta tag.)

------
Houshalter
I use referrer block for Chrome. I have only twice had anything break from it,
and it was a simple fix to whitelist that website. Disqus and coursera both
break without referrer.

I don't know why everyone doesn't block referrer. It seems like such a massive
breach of privacy to leak that information on every link you click.

~~~
leephillips
Referrers are useful and can be a friendly, automatic way of letting someone
know how you found their page. I've discovered many links to my pages on other
websites, and whole articles discussing my articles, through referrers. Since
none of the other pinging mechanisms ever gained universal traction, it's the
best thing we have, and I'm sorry that it's all but disappeared. And I
remember how amazed I was to discover the existence of "referrer spam" years
ago.

You can block referrers in a number of ways whenever you'd like, for example
with a simple bookmarklet:

[http://lee-phillips.org/norefBookmarklet/](http://lee-
phillips.org/norefBookmarklet/)

Finally, looking at search terms that led to your site can be very
entertaining.

------
IgorPartola
Don't you mean referer?

Edit: yes, I know. This was an HTTP joke. Not a very funny one. Here is
another one: what is the difference between a hippo and a zippo? One is very
heavy, the other is a little lighter.

~~~
malsun
Referrer is the correct English spelling. It's so easy to accidentally create
a bug by forgetting that the standard relies on a spelling mistake.

------
jstayton
Current browser support: [http://caniuse.com/#feat=referrer-
policy](http://caniuse.com/#feat=referrer-policy)

------
tempestn
Does anyone know the preferred (current) method of sending referrer directives
between the referrer-policy header[1] and the referrer directive under Content
Security Policy (CSP) 1.1[2]?

Since these specs are evolving, there is a lot of contradictory documentation
online, and it's tough to weed out what's the accepted solution (if there is
one). Presumably using headers (of some sort) is preferable to meta tags where
possible though?

Edit: As mentioned by davecardwell, the always/never/default settings, which
are referenced in my CSP link there, are deprecated. Perhaps the whole concept
of serving the referrer policy via CSP is as well?

[1] [https://w3c.github.io/webappsec-referrer-policy/#referrer-
po...](https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-
delivery) [2] [https://www.w3.org/TR/2014/WD-
CSP11-20140211/#referrer](https://www.w3.org/TR/2014/WD-
CSP11-20140211/#referrer)

------
obelisk_
I knew about what happened with the referrers when going from HTTP to HTTPS
but had not heard about the meta referrer and have been wondering why, even
though my own site is HTTPS I see so many bare domain referrers. Now I know.
Thank you both to author and submitter.

------
merb
Actually I like the fact that some people won't add a referrer meta. Not
everbody needs to know where I came from.

------
ComputerGuru
Google originally justified their blocking of search term data in HTTP
referrer fields as being due to the security implications of HTTPS vs HTTP.
The fact that they now use <meta name="referrer" content="origin"> proves it
was just an excuse to obscure that data, since they have it at their disposal
to transmit that information securely to the destination site.

~~~
byuu
All of this has always been about forcing everyone onto HTTPS at any cost.
Denying referral headers, not allowing HTTP/2 over HTTP, treating self-signed
certificates as the worst thing ever, soon putting red X'es in the URL bars,
etc.

It's all disgustingly heavy-handed. But they get away with it because most
people are on board with it. They seem to lack empathy of how this would look
if they weren't on board with the change. The general idea is a great one: who
doesn't love extra security? But all of those cons ... interfering with
caching, costing money for wildcard certificates, all the security
vulnerabilities in the TLS libraries, the (miniscule, but non-zero) extra
computational power required, the added setup difficulty (yes, even _if_ you
trust Let's Encrypt to execute code on your box, it's still an added burden),
putting trust in the CA system that has shown several major flaws already
(such as rogue certificates) ... all conveniently ignored or whitewashed away.

But all the posturing in the world won't be enough to eliminate HTTP from the
web. It's going to outlive all of us. Not even because people like me want it
to, but because there's just so much legacy code out there that's never going
to get touched. Millions of devices and applications that only speak HTTP,
that nobody's ever going to update. Hell, it's trivial to find Gopher proxy
layers, and that never even got 1% of the uptake that HTTP has today.

~~~
otabdeveloper
This would have been OK if HTTPS truly did increase security.

In reality, however, the sensitive part is the 'who' and 'when', not the
'what'. HTTPS makes sense for hiding passwords or bank data, for everything
else it's mostly pointless.

(If you've watched any police procedural shows you've noticed that they don't
need wiretaps to make an arrest, a destination phone number and time is all
that's needed.)

~~~
seabee
Have we already forgotten FireSheep?

------
EGreg
Or you could just, you know, not include sensitive information in URLs,
reducing the risk of it being leaked through sharing, referer, or other ways.
HTTPS only prevents MITM. You should still think about the design if your
site.

