Disclaimer: I'm the Firefox engineer who wrote the patch and the post.

We did a user research study measuring website breakage under various privacy protections:

https://blog.mozilla.org/data/2018/01/26/improving-privacy-w...

tl;dr - strict-origin-when-cross-origin was one of the protections with the lowest amount of breakage. Entering Private Browsing is a clear, strong signal that the user wants more privacy, so we started by implementing this protection in Private Browsing.

However, note that some advertisers demand that AdTech vendors must not serve their ads on certain kinds of pages. (e.g., https://support.google.com/adsense/answer/1348688?hl=en&topi...) Many of those agreements require full referrers to be able to audit the ad inventory.

So there are some concerns and trade-offs to make in this space.

In all seriousness: why should we care what ad companies want? Mozilla makes a browser, not an ad platform. Advertisers may have to adapt, but that's their problem.

In my opinion Mozilla should be actively hostile to ad companies, and go out of their way to ruin metrics

I don't think that's a good tactic. Google and other ad companies have plenty of money to spread disinformation against Mozilla, if they wanted to.

If Mozilla's users are saying “yes, this is good; please do more”, Mozilla can use that as a defence against any resistance from advertisers.

Then it would be better if Mozilla remains closer to neutral but leaves maximum space to the user for custom configurations, maybe using extensions.

Many of the ad serving SDKs slurp up all this data anyways and send it down using a request body, query string, or something that isn't the "Referer" HTTP header. I'm not sure how ad verification providers get this data, but if anything it's just going to mean less information leaking out from systems like DFP to the smaller ad tech firms. But firms like Google will still be able to figure out what path you were on.

Why don't websites just remove ad code from pages they don't want ads to appear on, instead of telling the ad server to not display it on such pages by using the referrer information? Seems like a convoluted way to solve the problem.

https://lists.w3.org/Archives/Public/public-webappsec/2014De... is a good run-down of referrer uses from the AdSense perspective.

No, the advertiser doesn’t want their ad to appear on a certain publisher’s web page (e.g. banks often can get in trouble if their ads are associated with certain kinds of content).

Ah ok. But why then doesn't the ad's embed code just contain the URL of the page it's on in the query string / POST data? The (website that shows the ad's) server knows what page it is providing.

I suspect it does? But that's spoofable by the ad aggregator in a way that the Referer header isn't. So much of ad design is (for better or occasionally for worse) defending against bad actors.

Thank you for your efforts. Features such as this are appreciated by, I'm sure, many of your users. It's a shame that the slating Mozilla has had recently hasn't been met by praise for work like this.

It depends on who “you” are in this case. If that “you” is a company that solely makes money by selling various behavioral data and has little care about various jurisdictions (which they really should, especially with GDPR, let a long “doing the right thing”), it might very well be useful to collect extra signals.

However, if “you” is a company that is in some other business, but collects analytics for the purposes of optimizing it’s product and figuring out what actually works for their users, then you don’t event want to run the risk of ingesting something private. Especially with exposure to different jurisdictions.

Think of it as the difference between a double-opt-in email list where you are very sure people want to receive the communications and an unsolicited spam list. If the user volunteers this data and it has some relevant business purpose, that’s great. However, if the user doesn’t know I have this info and wouldn’t want me to have it, then acting on that data could create a lot of negative emotions that as a company I wouldn’t want.

My speculation is that this is a compromise in some sense. The change here aligns with what private session is supposed to be.

Private browsing will(1) start out with no sessions (none from normal browsing mode), (2) provides automatic tracker protection, and (3) will clear sessions (cookies and history) on exit leaving no trace. Private browsing is great for a number of use cases such as debug/test web app with a new session, visit NSFW, or hide the fact you watch cat videos on your puppy-lover friend's computer.

So it makes sense to hide the referrer in private sessions opt-in automatically. As for the normal browsing, you can disable referrer. See [1].

I would like to see more privacy and security options to be shown in the preferences UI. about:config is "okay" but it feels like Windows registry, not good for user experience, even by developer standard when one just want to toggle on/off privacy and security settings.

[1]: https://askubuntu.com/questions/797135/how-to-disable-http-r...

> why would you not want this on non-private sessions

Information leaks. You click a link from your email to a news article. The URL for the news article has your email in it. Then you click an ad on the news article. The ad just got your email address.

Worse still - instead of an email address, it's a token that auto signs you in to your account with the news site.

Sites are pretty bad at sanitizing their outgoing referers.

I don't use anything but web mail (Fastmail) since 2002. I do my banking and email in one browser and my general browsing in a very locked down Firefox (Many about:config hacks, uBlock Origin, Decentraleyes, Webmail Ad Block, Privacy Badger, and No Coin) that blocks about everything save the actual content. I also run a Pi-hole. Keeping your actions compartmentalised keeps your privacy better controlled. Nothing is perfect, but keeping things separated is generally a better idea than not doing so.

If you're not aware of it, you might want to look into Qubes[0], it's an OS that uses virtualisation tech to compartmentalise applications from each other (and the host OS). So you can use your browser of choice for all uses, just in different VMs configured to retain/discard data as you want.

[0] https://www.qubes-os.org/

As I read it the parent is for it. He is actually saying it should be always the mode not just for private browsing.

To add to everyone else: got to start somewhere. Private browsing seems like a good place, and I've just taken advantage of the plumbing it introduces to set strict origin referer in non-private browsing too.

Hopefully, even though groovecoder doesn't mention the possibility, if this works well then we'll see it rolling into regular browsing too, or at least having some UI exposed, in the same way that tracking protection moved from being private browsing only to having an option to enable it in regular browsing.

Actually, now I think of it, I wonder if the two could sit behind the same preference in the end?

It might break websites that provide features based on the referrer (eg. a central authentication that redirects back to the original page)

I can't recall ever encountering a referer-based authorization scheme that included the path or querystring in its logic--although it seems likely some goofus has implemented it, somewhere.

I actually just finished implementing a very simple JWT single sign-on feature. We don't use the referer for the authentication/authorization. However, having the path/query in the referer does allow our partners to know what (if any) post-login redirect path/query to include in the JWT to provide end users a seamless re-authentication experience.

We could, of course, build the same functionality into our implementation without relying having the path/query in the referer.

I have seen sites where the "Download this foobar" link only works when the referrer is the "Details of this foobar" page, where the download link is placed. If you sent a referrer of some other page on the site, e.g. the "list of all foobars" page, downloads would fail.

Considering that referer is trivially spoofable, not a great idea to rely on it for anything really.

So are cookies, but you wouldn't say that it's a bad idea to rely on them. Spoofing is only useful if you know the value you need to spoof.

It's less common now that web developers have prioritized sane urls, but a lot of sites still have the actual page as a query param like /site.php?page=foo instead of just /foo. Stripping query params by default would render referrers useless on those sites.