use an appropriate value for network.http.sendOriginHeader

From #33534 (closed): In Firefox 70, the network.http.sendOriginHeader pref value was changed from 0 (never send Origin header) to 2 (always send). What value should Tor Browser use?

https://bugzilla.mozilla.org/show_bug.cgi?id=1424076
"Enable network.http.sendOriginHeader by default"

changed milestone to %Tor Browser: 10.0

added 1 deleted label

added 1 deleted label and removed 1 deleted label

added 1 deleted label

#32865 could be relevant here.

removed milestone %Tor Browser: 10.0

added 1 deleted label and removed 1 deleted label

mentioned in issue #33534 (closed)

removed 1 deleted label

added 1 deleted label and removed 1 deleted label

What value should Tor Browser use?

Default (unless I'm missing something). It shouldn't make a stick of difference, the only prefs that matter are cross origin

• network.http.referer.XOriginPolicy
  • control when to send a referer
  • 0=always (default), 1=only if base domains match, 2=only if hosts match
• network.http.referer.XOriginTrimmingPolicy
  • control the amount of information to send
  • 0=send full URI (default), 1=scheme+host+port+path, 2=scheme+host+port

changing XOriginPolicy from default WILL break things changing XOriginTrimmingPolicy to 1 or 2 should result in minimal, if any, breakage

mentioned in issue #40177 (closed)

removed 1 deleted label

added 1 deleted label

changed milestone to %Sponsor 131 - Phase 3 - Major ESR 102 Migration

added Backlog label

added Sponsor 131 label

added Q4 label

removed Backlog label

added Doing label

assigned to @richard

added Backlog label and removed Doing label

added Next label and removed Backlog label

assigned to @ma1 and unassigned @richard

added Doing label

The Origin header has been introduced specifically to address the shortcomings and unreliability of Referer, as a way of balancing privacy with the ability of web sites to recognize and mitigate cross-origin attacks; it sends just scheme://host:port (by definition) when serves this purpose, and therefore the default behavior should not be touched.

On the other hand, reducing the granularity of Referer to scheme://host:port for cross-site requests, instead of sending the full document URL, will prevent leaking potentially sensitive information (especially from the query string) and is very unlikely to break anything (nobody relies on Referer for "security checks" anymore, let alone on its path component and cross-site).

Should be noted that the latter behavior ha been the default for a couple years now (network.http.referer.defaultPolicy = 2, i.e. strict-origin-when-cross-origin), so no preference needs to be flipped.

Referer is still a navigational tracking mechanism, but sending nothing network.http.referer.XOriginPolicy = 2 breaks too much according to feedback (anecdotally, I don't see this, but embedded YT vids etc break) - the good news is that referrers should be the same for everyone (i.e origin + destination)

reducing the granularity of Referer to scheme://host:port for cross-site requests, instead of sending the full document URL, will prevent leaking potentially sensitive information (especially from the query string) and is very unlikely to break anything

this is my understanding as well from users of network.http.referer.XOriginTrimmingPolicy = 2

so no preference needs to be flipped

Are you sure. That's only a default policy and can be overriden by a site-controlled Referer Policy

@richard re-open please

PS: also some light reader for @ma1 https://portswigger.net/web-security/csrf

Are you sure. That's only a default policy and can be overriden by a site-controlled Referer Policy

Yes, it still can for now (in ESR, and even there not in top-level PB windows, see the network.http.referer.disallowCrossSiteRelaxingDefault.* prefs in 102 and beyond).

On the other hand, a site which explicitly decides to relax may do it for compatibility reasons while trackers could simply add a ?from=${document.URL} (more or less obfuscated) to any outbound request (as they do).

Anyway I'm all for switching network.http.referer.XOriginTrimmingPolicy = 2 as a forward-looking defense in depth, even in 11.5.x.

PS: also some light reader for @ma1 https://portswigger.net/web-security/csrf

Do you refer to Referer's (non pun intended) unreliability as a CSRF-mitigation mechanism (which I already mentioned in previous messages) or something else?

I didn't mean anything in particular about the link, I just found it relevant

closed

reopened

I think this ticket should actually stay closed, and the network.http.referer.XOriginTrimmingPolicy = 2 switch happen in #17228 (closed).

sure, we have a dupe :) you pick

wfm

closed

mentioned in issue #17228 (closed)