Tighter Control Over Your Referrers | Hacker News Reader

Tighter Control Over Your Referrers

blog.mozilla.org

79 pointsrobin_reala22 comments

It looks like Chrome is already supporting this as well:

> Enabled by default in desktop Chrome 21

https://www.chromestatus.com/feature/5126747842412544

Whether I use Chrome or Firefox individually, the fact that two major browsers already support it is very, very good for the internet as a whole.

It means it is likely to be supported by all the major browsers eventually. It means I can assume the implementation in the other major browsers will be fairly close to what I'm seeing right now. And most importantly, I can confidently recommend to my team that we add <meta name="referrer"> starting today.

On the user end, this can be controlled to a fine degree with the RefControl extension

https://addons.mozilla.org/en-US/firefox/addon/refcontrol/

I'm also a RefControl user, I've blacklisted only about 15 sites. I'm surprised how little the Referer header matters these days. Of course it should never matter at all, it's so easy to spoof.

No need for an extension, in about:config you can toggle network.http.SendRefererHeader from the default value of '2' to '0', which will disable all referer headers.

> No need for an extension, in about:config you can toggle network.http.SendRefererHeader from the default value of '2' to '0', which will disable all referer headers.

Some websites require the referrer to work; RefControl allows you whitelist exceptions, and also configure a few different options.

This breaks virtually all paid webfont services, messing up referring websites and frequently making them completely unusable.

Good point, but those paid webfont services were already blocked by my NoScript extension, so I see no changes from my end.

As far as sites which require a referrer header, it has been my experience that these are very few and far between. I get one occasionally and if the content is worthy, I'll briefly disable then re-enable my setting.

Not for everyone, I know, but it works well for me.

HeaderControlRevived has all of RefControl's features, but is able to manipulate more headers, plugging more potential privacy leaks.

https://addons.mozilla.org/firefox/addon/headercontrolrevive...

So this will totally break any deeplink protection. Where deeplink protection by referer checking (where an empty referer will allow the resource to be downloaded as well) was always effective enough since the web page author had no way to control the browser’s or users choice of sending a Referer header or not, now the author of a web page that is deeplinking resources is simply able to prevent a Referer header being sent, circumventing the protection mechanism.

Is there a reason why deep linking protection is good? I know there are arguably reasons why a site owner might want it, but any that make it so I should care?

Not sure about deep linking, but hotlinking protection is quite important if we want to enable people to self-host their content (pictures, videos, etc) instead of centralizing everything on Youtube and such.

I run a small forum which hosts photos uploaded by its users, and some guy (not even a member) decided to use one of them as his signature on another forum (orders of magnitude larger). He killed half of our monthly traffic cap in a couple of days, until I mod-rewrited hotlinked URLs to a disturbing image :D

EDIT: That said, a better anti-hotlinking mechanism, which wouldn't violate the user's privacy, would be to have a response header whitelisting the domains in which the resource could be embedded from. If someone were to hotlink an image, the browser would simply refuse to show it.

Your solution wouldn't help: my browser would still request the image from your server, and you'd have to send me at least the headers. That in itself could kill your traffic cap. Instead, my request should send you the domain on which I want to display the image, and then you can give me a 400 error.

Instead, my request should send you the domain on which I want to display the image, and then you can give me a 400 error.

But that tells me that a browser with a certain IP, user-agent and possibly even cookie ID is accessing a certain third-party site. I shouldn't have that information just because my image was hotlinked in that site.

And while my solution does still consume traffic, the idea would be discouraging the hotlinking in the first place. Why would anyone keep my image hotlinked if it didn't work?

Note that this is already broken in various cases, like when navigating from an HTTPS page to an HTTP page.

Hooray! Mechanism and not policy! This is an excellent improvement for the web.

I'm not sure correcting the spelling of 'referer' for the meta tag was a wise move.

This seems like a backwards incompatible change to the Internet in one browser only. While data-users shouldn't rely on user submitted data's accuracy (including the refer[r]er), unless Mozilla can show support from the W3C/other browser vendors, this seems worth a discussion.

The W3 standard for the meta referrer element was linked in this post:

http://www.w3.org/TR/referrer-policy/

Not only that, it doesn't break anything at all. Referer is a completely optional header, and all this does is introduce a <meta> tag for controlling that. I hope more browsers pick this up soon!

And also let me enforce my own setting.

Chrome has supported this since about 2011. It is not actually new. And because it was implemented before the WebKit/blink fork even Safari supports it as well. Firefox is the 3rd browser.

There's a W3C draft: http://www.w3.org/TR/referrer-policy/

Reply on news.ycombinator.com