
Tighter Control Over Your Referrers - robin_reala
https://blog.mozilla.org/security/2015/01/21/meta-referrer/
======
cag_ii
It looks like Chrome is already supporting this as well:

> Enabled by default in desktop Chrome 21

[https://www.chromestatus.com/feature/5126747842412544](https://www.chromestatus.com/feature/5126747842412544)

~~~
sounds
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.

------
forgotmypw
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/](https://addons.mozilla.org/en-
US/firefox/addon/refcontrol/)

~~~
tombrossman
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.

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

~~~
tombrossman
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.

------
rgj
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.

~~~
hyperpape
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?

~~~
icebraining
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.

~~~
IgorPartola
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.

~~~
icebraining
_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?

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

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

------
gburt
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.

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

[http://www.w3.org/TR/referrer-policy/](http://www.w3.org/TR/referrer-policy/)

~~~
jlogsdon
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.

~~~
cramforce
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.

