1457981 - Firefox private browsing stripping referrers too aggressively

Status: RESOLVED WONTFIX

(Firefox :: Private Browsing, defect)

Description

[Sankaku Complex]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36

Steps to reproduce:

This regards the recent changes to private browsing behaviour outlined here:
https://blog.mozilla.org/security/2018/01/31/preventing-data-leaks-by-stripping-path-information-in-http-referrers/
In short, Firefox in private browsing mode will by design no longer supply detailed referrers to "third-party" sites.


Actual results:

We operate several high traffic sites. Dozens of users have complained directly to us about their Firefox showing a hotlinking image in private browsing mode in place of the actual content it should have loaded, so I assume many more than directly complaining have been affected.

Investigating, this occurred because Firefox's private browsing mode stripped the referrer of image requests to image-hosting subdomains of a page-hosting domain, returning only the domain. Since the assets in question are never requested from the main domain, a logical anti-hotlinking policy is not to allow domain-only referrers and this is the rule our servers operate with (in fact prior to the advent of this new feature the only domain-only referrers we received were universally from bots and other non-human traffic).

Unfortunately, it would appear the "third-party domain" definition used by Firefox extends to "images.domain.com/file.jpg" when linked from "www.domain.com/page", and as a result private browsing traffic appears to be illegitimate traffic when using the existing referrer checking rules.

All we can do at present is suggest affected users use a different browser or refrain from using private browsing.


Expected results:

Whilst we appreciate the privacy respecting features of Firefox, and I am a longtime Firefox user myself, in this case they are applied a little excessively. Our Firefox users have clearly been inconvenienced by this change, and there is no privacy dimension impacted (after all, if we served the assets from the same domain/server as the originating page, we would receive the full referrers by default even in private browsing anyway...).

It would be great if the impact of this measure was reassessed, as clearly in our case there is not "minimal to no effect on web usability" if using private browsing breaks all the images on a site which was hitherto perfectly viewable in the browser, and is supported without issue by all other browsers in high privacy configurations.

Personally, I think the browser should be returning unaltered referrers to all subdomains of an originating domain to allow for situations like this, and out of consideration for the fact different subdomains on the same domain are unlikely to pose any privacy impact, compared to leaking referrer information to an entirely different domain.

Comment 1

[Luke Crouch [:groovecoder]]

Thanks for the bug report.

Have you tried setting an explicit Referrer-Policy of "no-referrer-when-downgrade" ?

Comment 2

[Sankaku Complex]

(In reply to Luke Crouch [:groovecoder] from comment #1)
> Thanks for the bug report.
> 
> Have you tried setting an explicit Referrer-Policy of
> "no-referrer-when-downgrade" ?

Thanks for looking into it.

No... because the server in question is a legacy one, it does not set CORS headers at all at present. I'm not sure if we can readily add it at the moment.

Also it seems that setting this would adversely impact the privacy of private browsing users, since they would then be sending full referrers to third parties (in our case, ad networks or any third party scripts used), though admittedly this might be preferable to the page not displaying any images.

Comment 3

[Luke Crouch [:groovecoder]]

FWIW, a Referrer-Policy header is un-related to CORS, if that helps you implement it?

We decided to make Firefox private browsing default to a "strict-origin-when-cross-origin" Referrer Policy if the website does not set one.

When web authors set the "no-referrer-when-downgrade" policy to mitigate this kind of breakage, we respect that. But as you observe - that means you need to implement your own policy, and you will expose your private browsing users to ad networks or third-party scripts (that aren't blocked by Tracking Protection, which is also on by default in Private Browsing).

This is a trade-off we've decided to make - to err on the side of protecting web-wide private browsing usage from data leaks, and to give web authors and developers their own way to mitigate any breakage.

Sorry we won't be able to fix this for you.