Sorry all! False alarm. I thought I stumbled onto some new major regression that broke a big banking site that got me all excited. But I didn't. It turns out while I did all the troubleshooting I could on this, the problem was with a single pref called: network.http.sendRefererHeader. It was set to 0 instead of the default of 2.
I'm honestly shocked it could break just loading a bank's homepage. I don't understand why it needs to know how I got to its homepage. It shouldn't need to know that. But I can imagine it breaking a bank site once you get past the login page. Many pages on that side of things would need to know what referred them there for security reasons I'm guessing.
So while I wasted a lot of time on this, I'm glad I learned this lesson because network.http.sendRefererHeader could've been breaking a lot more things for me causing me to blame the failures on the wrong things.
One epiphany I had afterwards was, why didn't Troubleshoot Mode disable this pref?!
I thought it was suppose to disable a lot of privacy related prefs. I'll file a bug to force Troubleshoot Mode to disable network.http.sendRefererHeader or reset it.
Although this pref did show up in the "Important Modified Preferences" list on the about:support page. But I did not look at it closely enough to spot it.
Privacy workaround:
I was able to fool Chase.com with this privacy pref instead:
network.http.referer.spoofSource = True
Cisa.gov does NOT fall for this though
Sorry all! False alarm. I thought I stumbled onto some new major regression that broke a big banking site that got me all excited. But I didn't. It turns out while I did all the troubleshooting I could on this, the problem was with a single pref called: [https://wiki.mozilla.org/Security/Referrer network.http.sendRefererHeader]. It was set to 0 instead of the default of 2.
I'm honestly shocked it could break just loading a bank's homepage. I don't understand why it needs to know how I got to its homepage. It shouldn't need to know that. But I can imagine it breaking a bank site once you get past the login page. Many pages on that side of things would need to know what referred them there for security reasons I'm guessing.
So while I wasted a lot of time on this, I'm glad I learned this lesson because network.http.sendRefererHeader could've been breaking a lot more things for me causing me to blame the failures on the wrong things.
One epiphany I had afterwards was, why didn't Troubleshoot Mode disable this pref?!
I thought it was suppose to disable a lot of privacy related prefs. I'll file a bug to force Troubleshoot Mode to disable network.http.sendRefererHeader or reset it.
Although this pref did show up in the "Important Modified Preferences" list on the about:support page. But I did not look at it closely enough to spot it.
Privacy workaround:
I was able to fool Chase.com with this privacy pref instead:
[https://wiki.mozilla.org/Security/Referrer '''network.http.referer.spoofSource''' = '''True''']
Cisa.gov does NOT fall for this though