wiki: revisit smart referer recommendation

[fxbrit]

the wiki mentions smart referer as a potential alternative to 1601 in case of breakage, and it also includes a couple tweaks (whitelist and strict mode).

however one of the default settings of SR is rewrite mode, quoting the readme of the project:

Rewrite Mode: Can be used to change what is sent to the server instead of the original referer header. The default (Send the URL you're going to as referer) is known to cause the least issues on most sites and is therefore recommended.

this means that out of the box SR is spoofing referers which is not a good idea for security, and in fact it's enforced false using 6002.

the wiki should recommend changing rewrite mode to "Send nothing".

[remyabel2]

It's been mentioned before changing the rewrite mode to Send nothing is the equivalent of setting network.http.referer.XOriginPolicy to 2. I've tried this and experienced breakage even when whitelisting and the entire reason to use Smart Referer in the first place is to avoid breakage.

Note that said security issue is specifically with CSRF which reads:

Another place where the Referer is useful is as a mitigation against cross-site request forgeries. In that case, a website receiving a form submission can reject that form submission if the request originated from a different website.

It's worth pointing out that this CSRF mitigation might be better implemented via a separate header that could be restricted to particularly dangerous requests (i.e. POST and DELETE requests) and only include the information required for that security check (i.e. the origin).

If I read this correctly, it implies that there is no security problem on sites that implement the second method.

[fxbrit]

I've tried this and experienced breakage even when whitelisting

that seems odd, because whitelisting would default referers to a normal behavior.

the entire reason to use Smart Referer in the first place is to avoid breakage.

at the cost of security, that's a big nope. if SR doesn't work even with the whitelist, imo it's best to relax network.http.referer.XOriginPolicy than it is to spoof.

there is no security problem on sites that implement the second method

but we do not know who, what and when, meaning that there's no guarantee that's used unless there are some stats on the internet to back this up.

[g-2-s]

Fwiw I use these settings #1326 (comment) and never experienced any breakage.

[remyabel2]

Fwiw I use these settings #1326 (comment) and never experienced any breakage.

Yeah I saw that. I tried it again and it worked. Not sure what happened last time.

[crssi]

@g-2-s and @remyabel2
One sample page for SR/Referer puzzle solving https://minecraft.directly.com/p/847dac72-da50-4256-b4aa-af1cdf60954c?r=34243073&et=2c99854c8082bcbc01808ada6de048ba&fe=true
See that:

[Thorin-Oakenpants]

maybe it's time to find a better referer extension. not saying that SR is broken, but the lack of activity for years (from memory) is not particularly inspiring especially given future changes that I think will impact (manifest 3, permissions, service workers background pages). I think sooner or later we're probably gong to need to drop this extension as no longer maintained

terms: (soz if I have this back to front) origin = where the item is held, destination = the site that requested it

So is there an extension that blocks cross-site (eTLD+1 + scheme) referrers by default (like TZP's 1601), has an allowlist for destinations where nothing is done (do not modify anything) as a simple unbreak fallback, and has a spooflist for destinations where it uses the origin - any spoof should be limited to scheme+host+port (like TZP's 1602). I don't think we need origin-destination complexity

So, most sites (YMMV) work fine. Then you get a site that won't load images, so you add to the spoof list, it works. Another site, videos and images won't load - you add it to the spoof list, if doesn't work - you add it to the ignorelist, it works

IDK if you can do anything about 6002 and CSRF except try and limit when spoofs are used, because there is no other way to unbreak something

Sorry for my ignorance, I do nto use SR and can't remember anything about it when I did a screenshot a few months ago

• Does SR or can SR essentially do that - BLOCK by default?

[fxbrit]

Does SR or can SR essentially do that - BLOCK by default?

yes, once rewrite mode is changed to Send nothing as referer, looking like a direct hit. at that point the user would need to either:

• set exceptions for websites that do not work;
• use a whitelist of some kind;
• disable SR by clicking on its icon.

but IDK if that's worth it when one could simply relax 1601. and also as you mentioned SR might stop working with manifest v3 on the way.

[Thorin-Oakenpants]

but IDK if that's worth it when one could simply relax 1601

blocking far outweighs relaxing. User goes to SiteA with youtube vid - why tell youtube your IP was on SiteA

[crssi]

this looks almost there: https://addons.mozilla.org/firefox/addon/referer-modifier/

Missing configuration of Source -> Target domain pair. 😢

[Thorin-Oakenpants]

but that doesn't mean we can't limit the damage, but we also don't need to complicate things

Smart Referer ... and it's probably too complicated with origin-source combos

referers aren't really the issue, it's the IP ... but that doesn't mean we can't limit the damage, but we also don't need to complicate things

All I want is

• send nothing by default
• whitelist sites (eTLD+1 + scheme) to unbreak shit for user's super regular sites
• anything else is up to the user and I don't have to explain it or add reams of stuff tot he wiki

What I don't want

• micro management

[crssi]

For example... I would like to have *.google*.* > *.google*.* to avoid breakages (see more examples https://github.com/crssi/Firefox/blob/master/Smart_Referer-Whitelist.txt)
So willing to reveal referers in the BigG "domain" but not willing to reveal for anything else that connects to BigG domains.

[Thorin-Oakenpants]

^ so you whitelist *.google*.* , they're not going to host anything on third parties

[crssi]

^^ Not sure I understand your saying. 😢
If I allowlist BigG, then BigG knows where I am stumbling over 3rd party connections to BigG on those sites?

❤️

[Thorin-Oakenpants]

Here's hoping uBO adds this - uBlockOrigin/uBlock-issues#1663 (comment) - then users can block by default but allow per eTLD+1. No Spoofing or affecting of CSRF. This is honestly the only way to do it IMO - simple on/off - I personally don't think we need any of the complexity of origin vs destination

And it would be one less extension for those who use Smart Referrer. Most users wouldn't want to disable all cross-site referers as per our default, it breaks too many platforms and properties. It's fine for me, but I'm also happy to use uBO to break most 3rd party anyway.

The referrer pref 1601 is probably the biggest pref users have an issue with. If uBO added a block/enable per-site scope for this, then we could make that pref inactive, and just add a referer note to the uBO setup instructions

[fxbrit]

that would be amazing and it would fit very well in uBO advanced mode (block everything and whitelist like in medium mode would be chef kiss).

[g-2-s]

this looks almost there: https://addons.mozilla.org/firefox/addon/referer-modifier/

I've been using Beta 1.0beta1 for some days now and it seems to do its job nicely, I think. Dev also looks active and eager to improve it further so that's a big bonus in my book.

[g-2-s]

I ask you to take a look at Referer Modifier again now that it has reached v1.1.0 and maybe really consider replacing Smart Referer with it.

[veloute]

currently trying out referer modifier - it definitely needs some more focus on ease-of-use, but it's working great so far.

[sith-on-mars]

Looks like referer modifier requires a lot of manual tweaking in order to make it effective. The default setting is almost the same as user_pref("network.http.referer.XOriginPolicy", 0) and user_pref("network.http.referer.XOriginTrimmingPolicy", 2) apparently, which is the setting I normally would use. I might be wrong on this.

[Thorin-Oakenpants]

closing as invalid - I will not be recommending any referer extensions in future, see linked issue below