Hacker News Reader

Comment by nly | Hacker News Reader

HTTP referers are evil. I've been using RefControl[0] to block 3rd party referers for years now.

[0] http://www.stardrifter.org/refcontrol/

The web wasn't built with privacy in mind. 3rd party cookies and HTTP Referers are just the low hanging fruit.

Why do you consider them evil? It's useful for a destination server to be given insight into the previous url and it doesn't expose any private information.

I suppose one might consider their previous url private information, but if that's the case you've go a lot more to worry about than http referers.

More to worry about, such as?

URLs aren't protected any less than cookies are, and cookies are the standard way of securing login tokens.

Heck with URLs you get the 'secure flag' cookie option for free!

Yes they are. Cookies are subject to the same origin policy. The Referer header is not.

I think you misread. grannyg00se said there is a lot more to worry about than http referers. We don't need a reminder that referer is a problem.

Your browsing behaviour in general is being recorded via user patterns, user agent strings, browser configuration, ip address, etc. An interested party can, in general, find out where your browser has been regardless of referer strings. What is so special about the url? It shouldn't contain any information that is meant to be secure.

It's a violation of browsing privacy. It's noone's business how or why I arrived at a webpage.

By what edict?

The general default behaviour has always been to let an http server know where you're coming from so that it can take whatever actions appropriate. I don't see how or why there is a fundamental violation of some "browsing privacy" rule here.

Perhaps this is a good reason to make referers subject to the same origin policy?

Becomes less and less of an issue as sites switch to HTTPS though, right?

Referrers are still sent if you're clicking an https link on an https site, iirc.

This never made sense to me, why was this behavior defined this way and why has no browser challenged it? A more rational rule would be something like "only send header if the referer url is http, or if the referer and destination have exact match hosts"

Because the spec and implementations came along well before we started putting HTTPS on everything, or even most/many things. Given the number of HTTPS->HTTPS links you would have run across in regular practice the spec and your proposal were probably more or less identical in practice.

As for why it's still that way... I'm sure no one has bothered to really think about it since.

Yes

> Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

https://tools.ietf.org/html/rfc2616#section-15.1.3

Huh, for some reason I thought there was a same domain policy there, but you're right. I guess the idea was just to prevent leaking URLs to a completely passive observer.

FWIW, the web would survive without Referer, but it is genuinely useful to site owners, especially in aggregate. Maybe a compromise would be to trim it to just domain rather than full path?

This "vulnerability" only affected HTTPS links, the article said.

Reply on news.ycombinator.com