Omit referrers on cross-origin requests from an RFC7686 address

[fmarier]

The special-use .onion domain name, defined in RFC7686, receives special treatment in the Tor browser and in Firefox: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/dom/security/ReferrerInfo.cpp#334-339

It seems like this behavior should be standardized since any browser could be setup to proxy traffic over the Tor SOCKS5 proxy.

[mikewest]

Is the StaticPrefs::network_http_referer_hideOnionSource() preffed on by default?

It looks like Mozilla's implementation doesn't allow a page's assertion of a laxer policy to override the .onion === none behavior. I wonder whether there are cases where the site wouldn't want that. Referrer-based ACLs, etc?

[annevk]

That's a good question, Firefox does not ship this by default: https://searchfox.org/mozilla-central/source/modules/libpref/init/StaticPrefList.yaml#9297-9302.

[fmarier]

Good catch, I hadn't noticed that this wasn't ON by default in Firefox, just in the Tor Browser. I just tested this with the test page I've been using to replicate the Tor Browser behavior in Brave and Firefox doesn't touch these headers when set to use a local Tor daemon as a SOCKS5 proxy. I updated the two-implementer note on the Fetch PR accordingly.

[fmarier]

I wonder whether there are cases where the site wouldn't want that. Referrer-based ACLs, etc?

It seems unlikely to me that a site would rely on receiving a .onion referrer for any reason because the majority of users coming from a .onion site will be using the Tor Browser, which doesn't send a referrer in this case. Unless it's to exclude users coming from a .onion site, but I don't know what the point of that would be.