discussion: redo 1600s referers section (& new prefs in 52+53) #5

Thorin-Oakenpants · 2017-02-18T07:06:36Z

The 1600: Referers section needs some love. We have some changes coming up in the next release (52). These are

Deprecated in 52+
1601: network.http.sendSecureXSiteReferrer
New in 52+ (currently in section 9999)
// 1600's: restrict the contents of referrers attached to cross-origin requests (FF52+)
// 0- 1- 2-scheme+hostname+port
// user_pref("network.http.referer.XOriginTrimmingPolicy", 2);
// 1600's: default referrer fallback override? (FF52+?)
// 0-no-referer 1-same-origin 2-strict-origin-when-cross-origin
// 3-no-referrer-when-downgrade (default)
// https://bugzilla.mozilla.org/show_bug.cgi?id=1304623
// user_pref("network.http.referer.userControlPolicy", 3);

I also came across this article released today: https://scotthelme.co.uk/a-new-security-header-referrer-policy/ which nicely describes what each type of referer does exactly. Might be a good ref for you @pyllyukko

The 1600's section currently has only one active pref, and recommends using an add-on. In 52, it could be completely inactive - this doesn't seem right - surely some of these 7 prefs by default could be tightened up? And I think the section still needs better explanation (It's getting a bit confusing). I don;t mind losing all the numbering and starting from scratch, so it's logical. @fmarier 's opinion here would be great. Especially what the inactive defaults should be. Do we set them at FF defaults, or at most private or at a balance for less site breakage - and the new ones, what do we do with those: the first of which I have not filled in what 0 or 1 means, and I'd also like someone else to confirm what I already have is ok/right, including the descriptions.

The text was updated successfully, but these errors were encountered:

publicarray · 2017-02-18T11:47:19Z

The blog from Scott Helme talks about the Referrer-Policy header. The header can be implemented by web developers on their site to control the referrer behavior on their domain. basically it belongs near the category of headers like the CSP (content security policy). I would assume where the settings conflict, the option where the least amount is send wins. Note I have not read the standard but I suppose at the moment it's a bit of an undefined behavior where the browser vendors can decide what takes precedence.

I agree on using an extension like Smart Referer. I guess FF preferences and the extension can compliment each other.

earthlng · 2017-02-18T14:06:07Z

The 2nd of the new prefs is now fixed for FF53. All it does is "If request’s referrer policy is the empty string, then set request’s referrer policy to "no-referrer-when-downgrade". (by default)
I'm not sure if it also sets that default-policy when the site doesn't set the referer policy header at all or when a site sets it to something less secure. I assume not. fe what happens when a site sets 'unsafe-url'? It seems that this pref will be totally useless in that case.
The pref gets increasingly more restrictive the lower the value. IMO we can at least safely set this to '2' (strict-origin-when-cross-origin) without causing any site-breakage. 0 or 1 likely will cause too much breakage.
I think this pref is nice to have but not good enough without some other prefs or an addon dealing with referrers.
In my user.js I have:
network.http.referer.XOriginPolicy;2
network.http.sendRefererHeader;1
which IMO makes other referrer addons obsolete, fe. uMatrix's 3rd-party spoofing.

crssi · 2017-02-18T17:23:40Z

If I have the 'network.http.sendSecureXSiteReferrer' = false, then aliexpress.com login page does not work.
So I have commented out this and I am relying to a superior referal handling uMatrix has. Don't even need to turn off referal spoof in uMatrix for aliexpress.com to work.

cheers

fmarier · 2017-02-18T19:08:53Z

network.http.sendSecureXSiteReferrer is not just deprecated, it's been removed entirely because it didn't make much sense. It instructs Firefox to leak the referrer on non-encrypted HTTP requests, where anybody watching the network can see it, while stripping it from HTTPS requests where it would be encrypted. It's kind of backwards to what a security/privacy-conscious user should do.

network.http.referer.userControlPolicy (which was added in 53) is about setting the default value of the site-controlled Referrer Policy. It's only the default though, and unlike the other prefs, sites can override this one. So I don't think there's any point in changing that one. It was added primarily so that we can experiment with changing the default in Private Browsing.

So I see three worthwhile recommendations:

use an extension to disable referrer and whitelist sites that break
set network.http.referer.XOriginPolicy = 2 if you don't mind the occasional breakage
set network.http.referer.XOriginTrimmingPolicy = 2 otherwise

Note that restricting the referrer on the same site doesn't really buy you anything because a site can always see you in their access logs. So network.http.referer.XOriginPolicy = 2 is pretty much as strong as network.http.sendRefererHeader = 0 IMHO.

Atavic · 2017-02-18T20:02:32Z

uMatrix handles referrer-spoof:https://github.com/gorhill/uMatrix/wiki/Per-scope-switches

smart-referer has a whitelist.txt acting as a workaround for troubling sites.

fmarier · 2017-02-18T20:15:44Z

To me deprecated means removed.

"Deprecated" usually means it's still there but not for long and you should stop using it. It's the step before the actual removal :)

network.http.referer.XOriginTrimmingPolicy: in the notes in the js, I do not have the definitions for the values 0 and 1: Currently, as pasted in post1, I have 0- 1- 2-scheme+hostname+port. What exactly are they?

The values are "documented" in modules/libpref/init/all.js:

0: don't trim the referrer, send as much as you would normally
1: remove the query string (the stuff after ? in URLs)
2: remove the path and the query string, leaving just the scheme, hostname and port (e.g. https://example.com:8888/foo/bar.html?id=1234 becomes just https://example.com:8888)

fmarier · 2017-02-18T20:21:17Z

uMatrix handles referrer-spoof

Note that, as I mention briefly in my referrer blog post, spoofing increases your exposure to cross-site request forgeries. Some sites use the referrer header to detect POST requests originating from other sites and block them. By spoofing, you enable the attackers to work-around this protection.

A more secure (and equally privacy-protecting) option is to strip cross-origin referrers and leave same-origin referrers alone (network.http.referer.XOriginPolicy = 2).

earthlng · 2017-02-19T15:45:38Z

"By spoofing, you enable the attackers to work-around this protection."
Oh wow, I never thought about that. I'd hope that site admins would at least check the full url+path
if($_SERVER['HTTP_REFERER'] !== 'https://domain.com/page.html') die("");
...but the reality is probably more grim. If they would do that, the uMatrix spoofing would still be good enough.

I think if we set at least one of the referer-prefs we should also enforce the default values for every other ref-pref. I suggest we set network.http.referer.XOriginPolicy to 1 (less breakage) or 2 (more secure), and an optional recommendation to also set network.http.sendRefererHeader to 1 (to prevent sending the header to resources)
The problem with network.http.referer.XOriginTrimmingPolicy is IMO that if a site does the Referer-check with the full path as above, setting this to 2 would break that site, even though it does the ref-check in the best possible way.

crssi · 2017-02-20T20:00:56Z

Observations... I have tested for now functionality on login page at aliexpress.com: https://login.aliexpress.com/
Why aliexpress.com? No real reason, just cant recall any other. ;)
If you have any ideas for any other site,you can let me know and I will go over all settings from most restricted to lowest restrictions to spare you a time resources. ;)

Those settings are most restricted where aliexpress.com login still works:
network.http.referer.XOriginPolicy = 1 (more than 1 breaks)
network.http.referer.XOriginTrimmingPolicy = 2
network.http.referer.spoofSource = true
network.http.referer.trimmingPolicy = 2
network.http.sendRefererHeader = 2 (less than 2 breaks)
network.http.sendSecureXSiteReferrer = true (false breaks, I know... deprecated or to be soon)

I have not drilled down yet if this makes any senses and if some setting exclude any other or even nulls the idea totally.
Any comments?

earthlng · 2017-02-21T20:08:17Z

@crssi, thank you, but there's probably some overlap with a few of them.

Did you test in FF51? - because then network.http.referer.XOriginTrimmingPolicy doesn't do anything yet and you can ignore that for now.
IMHO, spoofSource is pretty bad and should never be enabled.
trimmingPolicy vs XOriginTrimmingPolicy - one is probably enough.

I've come to the conclusion that we should only set XOriginPolicy to 1, so less breakage, maybe with a note to set it to 2 for people who don't mind the occasional breakage, and to enforce the default values for everything else. If something breaks it would be only 1 pref they'd need to temporarily change.

changing XOriginTrimmingPolicy only causes unnecessary breakage when XOriginPolicy is set to 1 or 2.
-> the server(s) see your requests and where you came from in the logs anyway.

With all the todos because of the move to github I think we will deal with all ref-prefs when FF52 is released, but if you would like to help out until then, it would be very helpful if you set XOriginPolicy to 1 and leave everything else on default and test if you encounter any more breakage. I suspect it should be just fine and not cause any breakage, and if you could confirm that, it would help me to convince Pants to include XOriginPolicy = 1, finally ;)

earthlng · 2017-02-21T20:42:06Z

@fmarier
network.http.referer.userControlPolicy
It was added primarily so that we can experiment with changing the default in Private Browsing.

Can you elaborate on that? How does that any good for PB when a site is in full control of it? Is it enforced in PB or how does that work? I don't understand how one pref can do one thing in normal mode and something else in PB. Especially since it doesn't really do anything in the first place.
Is the plan to eventually 'overwrite' more than just "empty string", ie. unsafe-url etc, and enforce that value?

ps. Thank you so much for participating in our little project here! I never imagined we would ever have 'direct access' to a freakin' Security Engineer from mozilla! #mindblown

crssi · 2017-02-22T13:08:28Z

@earthlng Yes, I am on FF51.
Will do some new tests.
If you wish me to test some specific settings, let me know.
Can't do it now or today, but I will do it in the next few days, since a life came in between. ;)

crssi · 2017-02-22T13:43:24Z

@earthlng
Please let me know exactly what you wish me to set for the following list (note me also if you wish me to remove the specific setting entirely) and I will do the tests ASAP. This way I can try to do it today.

Feel free to add some, if I have missed it:
network.http.referer.XOriginPolicy
network.http.referer.XOriginTrimmingPolicy
network.http.referer.spoofSource
network.http.referer.trimmingPolicy
network.http.sendRefererHeader
network.http.sendSecureXSiteReferrer

earthlng · 2017-02-22T15:39:34Z

@crssi a life came in between - meaning you had a baby?? in that case - Congratulations my friend!
Take care of your newborn then and forget all the testing! What are you still doing here?! :)

Otherwise, it would be great if you only set network.http.referer.XOriginPolicy = 1, and set/reset/enforce all the others to the default values (including network.http.sendSecureXSiteReferrer) and just do your regular browsing. And see if you encounter any site-breaks and when you do, change XOriginPolicy to 0 in about:config and check if that is what's causing it.
I'm doing the same but with XOriginPolicy = 2 and so far I haven't noticed any problems at all.
But I'm not using a lot of sites with logins so that doesn't mean much.

You're still well-protected with that one pref only, because it doesn't send any ref-headers to 3rd party sites:

1 => send a referrer only when the base domains are the same
2 => send a referrer only when the full hostnames match

crssi · 2017-02-22T17:22:11Z

@earthlng Lol, no. I already have a few kids, little devil gems :).
It just mean that I am in a finish line of one biggest project, which was taking me a lot of socializing part of my life in the past half of year.
Now I can play more with the kids and even go grab a beer with my friends. ;)

Will do the suggested settings, make the referral tests and test the sites.

crssi · 2017-02-22T20:50:38Z

@earthlng OK, I am back and you were right.. everything on default and only network.http.referer.XOriginPolicy = 1 works perfectly.
Tried every "sensitive" site I remembered and no problems. If I find something in the next days, will report ASAP.

fmarier · 2017-02-22T21:03:26Z

Can you elaborate on that?

There are multiple ways to make users safer on the web. For example:

give users more control / extra security settings they can turn on (whether visible in preferences or hidden in about:config)
picking safer defaults for the web

As a user, if you set the maximum referrer to origin, a site won't be able to request more than that. As for the defaults, even if sites can override most, most won't, so safer defaults do increase the security of the web as a whole. Doing it in Private Browsing first allows us to try some things in a less risky way and also matches the expectations of privacy that users have when they go into that mode. That's why we did tracking protection in private browsing first.

ps. Thank you so much for participating in our little project here!

I'm also a privacy nerd at heart, so I would be interested in this project even if I weren't working on Firefox :)

publicarray · 2017-02-22T21:46:48Z

I have been using network.http.referer.XOriginPolicy = 2 with no breakage so far. I also had network.http.sendRefererHeader = 1 (only send referrer when links are clicked) however this broke some admin actions in bitbucket for example deleting a repository. So I don't recommend setting sendRefererHeader unless you can live with some breakage. @earthlng I agree that it should be optional.

I also think that network.http.referer.XOriginPolicy = 1 is a reasonable default to prevent breakage. People can always set it to 2 if they want to.

crssi · 2017-02-22T22:29:45Z

network.http.referer.XOriginPolicy = 2 breaks https://login.aliexpress.com while network.http.referer.XOriginPolicy = 1 works OK.
Not that I am inclined to this particular site (my folks are), but its a good referer testing playground. ;)

crssi · 2017-02-25T11:58:36Z

network.http.sendSecureXSiteReferrer = false also breaks, guess, which page... lol
FF default value is "true", if I am not mistaken... since I will be deprecated in FF52, I wildly guess that FF52 will behave as it would be set to "true"?
Is there any need to force it to false?

earthlng · 2017-02-25T14:58:38Z

@crssi no, you don't need network.http.sendSecureXSiteReferrer = false when network.http.referer.XOriginPolicy is set to 1 or 2. see @fmarier's comment here: #5 (comment)

that FF52 will behave as it would be set to "true"?

Yes, that's correct afaik

Atavic · 2017-03-06T15:57:07Z

👍 @fmarier url.

1600: An extension could be proposed here? As https-by-default.

Visit about:config and set browser.urlbar.trimURLs to false to not hide the "http://" prefix by default.

https://github.com/Rob--W/https-by-default#firefox
0804: false

fmarier · 2017-03-06T16:50:18Z

Is there anything technical that I screwed up? Or left out? eg is no trim the same as full URI?

Yes, if you don't trim, then you get the full URI (unless the browser would already trim it or suppress it like when it's an HTTPS-to-HTTP downgrade).

The only thing that's not quite right IMHO is the guidance around Do Not Track. While it is widely ignored, there are a few popular sites / frameworks that do actually honor it and reduce the amount of tracking they do server-side when they see it: Twitter, Medium.com and also Piwik (Open Source analytics package). Given it's a single bit of entropy (on / off) and that it helps on some popular sites, I personally choose to leave it ON.

Also I think you can omit privacy.donottrackheader.value, it doesn't do anything useful anymore and has been removed.

earthlng · 2017-03-06T17:41:45Z

@fmarier
re: DNT - do you know why mozilla disables DNT by default?
re: downgrade - apart from network.http.referer.userControlPolicy (if it's not overwritten by the site) is there something in Firefox that always prevents sending referrer headers from HTTPS-to-HTTP?
Does network.http.referer.XOriginPolicy set to 1 or 2 also include the scheme? f.e when I click a link on https://www.example.com to http://www.example.com/ or vice versa

@pants, if I understood @fmarier's comment correctly, he said to either set network.http.referer.XOriginPolicy OR network.http.referer.XOriginTrimmingPolicy. IMO if we set network.http.referer.XOriginPolicy then also changing the default of network.http.referer.XOriginTrimmingPolicy only causes unnecessary breakage and has no additional benefits. @fmarier, please correct me if I'm wrong.

IMO we should also enforce 1606, and maybe even set it to 2 instead of 3.

earthlng · 2017-03-06T17:47:00Z

@pants, I think you can remove the ALL and CROSS ORIGIN, because the latter also apply for same-origin, and it's slightly confusing and also incorrect.

earthlng · 2017-03-06T18:08:52Z

We can also include network.http.enablePerElementReferrer and set it to whatever, I'd say true, because it doesn't really matter if the other Ref-prefs are set in a good way.
It's under to investigate in Issue#20

fmarier · 2017-03-06T18:19:19Z

re: DNT - do you know why mozilla disables DNT by default?

That's required by the DNT specification. It's intended to be a signal that the user sends to the site. If it were the default, then it wouldn't be a signal because it would be more likely that the user doesn't know anything about DNT and simply didn't change the defaults.

We did however choose to turn it on when the user has tracking protection enabled. By turning on tracking protection, the user is sending a signal that they don't want to be tracked, so it makes sense to also send that through the DNT header.

re: downgrade - apart from network.http.referer.userControlPolicy (if it's not overwritten by the site) is there something in Firefox that always prevents sending referrer headers from HTTPS-to-HTTP?

Not sending referrers when going from HTTPS to HTTP is the default behavior of all browsers.

Does network.http.referer.XOriginPolicy set to 1 or 2 also include the scheme? f.e when I click a link on https://www.example.com to http://www.example.com/ or vice versa

It's only looking at the hostname and not the scheme.

We can also include network.http.enablePerElementReferrer

That's a partial feature flag that's likely to be removed later. There's no harm in setting it to its default value, but it's not a particularly useful user control. It allows sites to trim the referrer on links and images for example, on an individual basis.

earthlng · 2017-03-06T18:19:23Z

network.http.referer.userControlPolicy

I'm not sure if it also sets that default-policy when the site doesn't set the referer policy header at all

it does

... or when a site sets it to something less secure.

it doesn't

fmarier · 2017-03-06T18:24:09Z

I understood @fmarier's comment correctly, he said to either set network.http.referer.XOriginPolicy OR network.http.referer.XOriginTrimmingPolicy

XOriginPolicy exists to disable cross-origin referrers. XOriginTrimmingPolicy is for reducing cross-origin referrers. So in general, if you use XOriginPolicy, you don't need the other one because it won't do anything (i.e. there's nothing to trim if the referrer is already empty).

earthlng · 2017-03-06T18:59:29Z

Not sending referrers when going from HTTPS to HTTP is the default behavior of all browsers.

@fmarier, then why is there a need for things like no-referrer-when-downgrade?
And when you say default behavior, why not make it the only behavior?
Can we enforce the default behavior, and if so, how?
Sorry for asking so many questions ;)

fmarier · 2017-03-06T19:45:41Z

why is there a need for things like no-referrer-when-downgrade?

Because we need a name for the default behavior :) no-referrer-when-downgrade is the referrer policy used on a page unless the site changes it to something else (or the user via http.referer.userControlPolicy).

And when you say default behavior, why not make it the only behavior?

Because it sends the full URI as the referrer in all cases other than HTTPS-to-HTTP. We want sites to be able to opt into sending less information in their referrer if they want to.

Can we enforce the default behavior, and if so, how?

A site cannot ask for more referrer than what the user allows via trimmingPolicy and XOriginTrimmingPolicy. If you use the recommended user.js settings, the browser will enforce a much stricter behavior than the default.

earthlng · 2017-03-07T14:55:49Z

domain = wp.com
host - wp.com/example/
^^ right?

no, 1=only if base domains match, 2=only if hosts match
1 = www.wp.com also sends referrer to subdomain.wp.com for example
2 = www.wp.com only sends referrer to www.wp.com/*

Since our recommended policy revolves around 1603+1604 I would number them 1601+1602.
if you want to recommend a block-all/whitelist-some approach with an addon, we should recommend what addon(s) we/you think does the job.
I'm only using XOriginPolicy=2 and have disabled the spoofing in uMatrix, so I can't talk to that.

earthlng · 2017-03-07T15:24:53Z

@fmarier, you miss-understood my question.
What I was trying to say is, if the default behavior in all browsers to not send Referer Headers from HTTPS to HTTP is solely based on an opt-out basis for websites, then that's not a very good default behavior IMO.
My question was, why don't you make it so that referrers are NEVER sent from https to http?
ie. replace/overwrite unsafe-url with no-referrer-when-downgrade and add another check before processing origin or origin-when-cross-origin, something like:

if source.scheme == https and destination.scheme == http then removeHeader('Referer')
elseif policy == origin then blabla
elseif policy == origin-when-cross-origin then blabla

If you use the recommended user.js settings, the browser will enforce a much stricter behavior than the default.

Yes, I totally understand that, but even with XOriginPolicy=2, when I click a same-origin http-link on a https site that uses unsafe-url, origin or origin-when-cross-origin, the Referer Header would still leak, or not?
I know it's not really much of a "leak" to the server but it could perhaps be considered a leak in a MITM type scenario, or for NSA-style meta-data collection. Or is my slightly paranoid mind going crazy here? ;)

fmarier · 2017-03-07T16:03:58Z

What I was trying to say is, if the default behavior in all browsers to not send Referer Headers from HTTPS to HTTP is solely based on an opt-out basis for websites, then that's not a very good default behavior IMO.

My question was, why don't you make it so that referrers are NEVER sent from https to http?
ie. replace/overwrite unsafe-url with no-referrer-when-downgrade

The main reason why the referrer policy allows sites to work around the default restriction (the one that prevents HTTPS-to-HTTP referrers) is that it's preventing some sites from switching their main site to HTTPS. It's possible we'll be able to remove this ability later once HTTPS adoption (and HTTP deprecation) has progressed further.

Yes, I totally understand that, but even with XOriginPolicy=2, when I click a same-origin http-link on a https site that uses unsafe-url, origin or origin-when-cross-origin, the Referer Header would still leak, or not?

First of all, just to be clear on the terminology, http://example.com is not same-origin with https://example.com because the scheme and port need to match. Origin is scheme+host+port, so http+example.com+80 v. https+example.com+443 in this example. So this is a cross-origin load.

Secondly, despite the name, XOriginPolicy doesn't compare origins, it compares hostnames (e.g. mail.example.co.uk) or base domains (e.g. example.co.uk). It doesn't look at scheme or port.

So if you have a page on https://example.com/foo.html which loads resources from http://example.com, then XOriginPolicy = 2 will not block any of the referrers since the hostname is the same. If the site changes the default referrer policy, then http://example.com resources will receive a referrer of:

https://example.com/foo.html, in the case of unsafe-url
https://example.com in the case of origin
https://example.com in the case of origin-when-cross-origin

publicarray · 2017-03-08T01:29:52Z

Not sure if relevant but there is a Google Chrome plugin called Referer control: https://chrome.google.com/webstore/detail/referer-control/hnkcfpcejkafcihlgbojoidoihckciin
This could become useful once the new Add-on Api is developed further

earthlng · 2017-03-08T11:32:54Z

So in general, if you use XOriginPolicy, you don't need the other one because it won't do anything (i.e. there's nothing to trim if the referrer is already empty).

If XOriginPolicy=2 then XOriginTrimmingPolicy=[1|2] will trim the Referer header when a scheme or port change happens on the same host.
If XOriginPolicy=1 then XOriginTrimmingPolicy=[1|2] will trim the header same as above PLUS also when the sub-domain changes. to illustrate the last part:

start on http://www.ghacks.net/category/windows/ and click on Email
the document for http://www.ghacks.net/category/email/ gets loaded and will have Referer: http://www.ghacks.net/category/windows/
the email page loads http://cdn.ghacks.net/wp-content/themes/magatheme/img/email.png and that request has the header trimmed: Referer: http://www.ghacks.net/

So that confirms why I thought we shouldn't set XOriginTrimmingPolicy=2 unless XOriginPolicy=2, because it causes unnecessary breakage with no additional benefits IMHO.

earthlng · 2017-03-08T12:44:30Z

Love your commit :)
Now, if you allow me one last suggestion, to make this really great and follow @fmarier's recommendations.

So I see three worthwhile recommendations:
use an extension to disable referrer and whitelist sites that break
set network.http.referer.XOriginPolicy = 2 if you don't mind the occasional breakage
set network.http.referer.XOriginTrimmingPolicy = 2 otherwise

we already recommend to use an extension - check
we have a note to change XOriginPolicy=2 for better protection but with more breakage - check
if we could add a note that if someone sets XOriginPolicy=0 we recommend to also set XOriginTrimmingPolicy=2 -- well, that would be perfect and we can lay this to rest once and for all.

earthlng · 2017-03-08T15:34:17Z

Yes, that's even better. But needs some clarification, like what does Leave XOriginPolicy (1603) at default mean? is it our default (1) or the default default (0)?

Option 2: As per the settings below: Set XOriginPolicy (1603) at to 1 (less breakage)
or 2 (more breakage) and leave XOriginTrimmingPolicy (1604) at default (0)
Option 3: ~~Leave~~ set XOriginPolicy (1603) ~~at default~~ to 0 and ~~set~~ XOriginTrimmingPolicy (1604) at to 2

earthlng · 2017-03-08T16:37:04Z

The way I see it, in order of breakage

I can deal with a lot of breakage and don't mind doing it, if it helps security/privacy/etc but Option1 ("our" recommended option) is not something I personally would even want to do. And it is so "breaking" that there's also the risk that users will end up allowing way too much permissions. fe. facebook.com > send referer everywhere. And hence they end up less protected than using option 2 or 3 instead.
You said yourself that you did it for a while and it broke a lot of sites and was a pain to whitelist.
Until recently I only spoofed to 3rd-party with uMatrix, so anything better than that is already an improvement IMO.

But anyway, I see that you edited your proposal and it's fine. (is it "to set at" or "to set to"? - i think it's "leave at" and "set to", but that's just nitpicking on a high level :) )

earthlng · 2017-05-02T12:15:22Z

afaik it can not be "read" but it can certainly be observed by a website in their logfiles. They won't know which pref or addon you use to spoof, trim or remove the Referer but they will know that you do and which one of the 3 it is.

The guy who asked the question said he removes the header anyway so that overwrites all the other prefs, including network.http.referer.userControlPolicy. An addon could however still add it back in.

is it sent as an HTTP header ?

The referer policy header is sent by the server, not the client. But if a https site (without a Referer Policy header!) embeds an image from one of their own (sub)domains over HTTP instead of https then the default value (3) for network.http.referer.userControlPolicy will remove the header for that image request, which will be visible in the logfiles.

fmarier · 2017-05-02T16:31:24Z

What @earthlng said is right. The value of the pref isn't directly visible to websites, but it can be inferred to some extent based on the effect that it has in trimming or suppressing the referrer.

The same is true of all of the of the other referrer prefs. A site can tell that something is filtering the referrers, but they can't tell exactly what it is. It could be a proxy server for example.

earthlng · 2017-05-02T16:43:44Z

there is no such bloody extension to block all and whitelist per domain.

Once it's fixed Negotiator should be able to do that

ghost · 2017-09-19T05:50:36Z

network.http.referer.XOriginPolicy=1 broke login to my ASUS router (DSL-N17U). I spend way too much time troubleshooting this. Strangely enough, network.http.referer.XOriginPolicy=2 somehow works, go figure. I set it to 0 though and handle referers solely via uMatrix now.
Hope this helps others dealing with this..

crssi · 2017-09-19T11:02:39Z

^^ A network glitch.
Like 192.168.* is private, the whole 10.* is private (10.0.* is not correct). ;)
See https://en.wikipedia.org/wiki/Private_network

Thorin-Oakenpants added discussion enhancement labels Feb 18, 2017

Thorin-Oakenpants mentioned this issue Feb 20, 2017

sticky: add-ons #12

Closed

Thorin-Oakenpants mentioned this issue Mar 7, 2017

network.http.sendSecureXSiteReferrer #40

Merged

Thorin-Oakenpants closed this as completed Mar 7, 2017

fmarier mentioned this issue Mar 8, 2017

Rewrite Referer preferences/section pyllyukko/user.js#227

Closed

Thorin-Oakenpants changed the title ~~discussion: referers section 1600 & new prefs in 52~~ discussion: redo 1600s referers section (& new prefs in 52+53) Mar 9, 2017

Atavic mentioned this issue Mar 12, 2017

What about network.http.enablePerElementReferrer ? #59

Closed

Atavic mentioned this issue Apr 2, 2017

referrer add-ons discussion #76

Closed

This was referenced Apr 27, 2017

uMatrix 0.9.3.6 user-agent leak gorhill/uMatrix#771

Closed

[FYI] Spoofing Referrer headers in uMatrix gorhill/uMatrix#773

Closed

Atavic mentioned this issue Jul 23, 2017

Typos and some questions #178

Closed

10 tasks

discussion: redo 1600s referers section (& new prefs in 52+53) #5

discussion: redo 1600s referers section (& new prefs in 52+53) #5

Comments

Thorin-Oakenpants commented Feb 18, 2017

publicarray commented Feb 18, 2017 • edited Loading

earthlng commented Feb 18, 2017

crssi commented Feb 18, 2017

fmarier commented Feb 18, 2017

Atavic commented Feb 18, 2017

fmarier commented Feb 18, 2017

fmarier commented Feb 18, 2017

earthlng commented Feb 19, 2017 • edited Loading

crssi commented Feb 20, 2017 • edited Loading

earthlng commented Feb 21, 2017 • edited Loading

earthlng commented Feb 21, 2017 • edited Loading

crssi commented Feb 22, 2017

crssi commented Feb 22, 2017

earthlng commented Feb 22, 2017 • edited Loading

crssi commented Feb 22, 2017

crssi commented Feb 22, 2017 • edited Loading

fmarier commented Feb 22, 2017

publicarray commented Feb 22, 2017 • edited Loading

crssi commented Feb 22, 2017

crssi commented Feb 25, 2017 • edited Loading

earthlng commented Feb 25, 2017

Atavic commented Mar 6, 2017 • edited Loading

fmarier commented Mar 6, 2017

earthlng commented Mar 6, 2017

earthlng commented Mar 6, 2017

earthlng commented Mar 6, 2017

fmarier commented Mar 6, 2017

earthlng commented Mar 6, 2017

fmarier commented Mar 6, 2017

earthlng commented Mar 6, 2017

fmarier commented Mar 6, 2017

earthlng commented Mar 7, 2017 • edited Loading

earthlng commented Mar 7, 2017

fmarier commented Mar 7, 2017

publicarray commented Mar 8, 2017

earthlng commented Mar 8, 2017 • edited Loading

earthlng commented Mar 8, 2017 • edited Loading

earthlng commented Mar 8, 2017 • edited Loading

earthlng commented Mar 8, 2017

earthlng commented May 2, 2017

fmarier commented May 2, 2017

earthlng commented May 2, 2017

ghost commented Sep 19, 2017

crssi commented Sep 19, 2017

publicarray commented Feb 18, 2017 •

edited

Loading

earthlng commented Feb 19, 2017 •

edited

Loading

crssi commented Feb 20, 2017 •

edited

Loading

earthlng commented Feb 21, 2017 •

edited

Loading

earthlng commented Feb 21, 2017 •

edited

Loading

earthlng commented Feb 22, 2017 •

edited

Loading

crssi commented Feb 22, 2017 •

edited

Loading

publicarray commented Feb 22, 2017 •

edited

Loading

crssi commented Feb 25, 2017 •

edited

Loading

Atavic commented Mar 6, 2017 •

edited

Loading

earthlng commented Mar 7, 2017 •

edited

Loading

earthlng commented Mar 8, 2017 •

edited

Loading

earthlng commented Mar 8, 2017 •

edited

Loading

earthlng commented Mar 8, 2017 •

edited

Loading