1928294 - Consider how Referrer from Refresh affects ETP.

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, enhancement)

Description

[Tess Hoffman [:zrhoffman]]

As described in bug 1479017 and its linked webcompat report, Firefox not sending a referrer from a <meta> refresh or HTTP Refresh header is a webcompat issue.

However, fixing this issue will include sending a referrer in a new place that Fx previously did not, which could be a tracking issue.

Once sending a referrer from refreshes is implemented behind a pref in bug 266554, it should be easier to evaluate what is needed, with respect to tracking protection, in order to enable it by default (bug 1928290, bug 1928291).

Comment 1

[Tess Hoffman [:zrhoffman]]

Hi Tim, for awhile <https://github.com/mozilla/gecko-dev/commit/74bfd1dd41f#diff-e570c28d01a02f86725b88999035c7a9ff8d86185c203c364b1be0584c6d1a7bR6981-R6982> Fx has intentionally not sent a referrer when navigating from <meta> refreshes or the Refresh header, and there have been efforts over the years <https://phabricator.services.mozilla.com/D35810> to keep that referrer hidden.

But as noted in bug 1479017 comment 4, not sending a referrer with Refresh breaks the expectations of a major site, so (currently-disabled) pref network.http.referer.sendFromRefresh was added to enable that functionality in bug 266554.

Is any tracking mitigation needed before network.http.referer.sendFromRefresh is enabled by default in bug 1928291? WDYT?

Comment 2

[Tim Huang[:timhuang]]

Per Bug 1479017 comment 2, it makes sense to send a referer header in this case. For tracking mitigation, we have enforced the strict-origin-when-cross-origin referrer policy for cross-site requests, which covers the case here. So, I think we don't need extra protection here.

But we might want to have a test to ensure the protection is still working for meta refresh cases. Note that we don't enforce the top-level navigations due to webcompat reasons.

Comment 3

[Tess Hoffman [:zrhoffman]]

Attachment: Bug 1928294 - Test coverage to ensure tracking protection is applied to cross-site refreshes. r=#anti-tracking!

This only tests cross-site refreshes in an iframe. Tracking protection
is not applied to top-level cross-site refreshes, but that is
intentional for webcompat reasons.

Comment 4

[Tess Hoffman [:zrhoffman]]

(In reply to Tim Huang[:timhuang] from comment #2)

Per Bug 1479017 comment 2, it makes sense to send a referer header in this case. For tracking mitigation, we have enforced the strict-origin-when-cross-origin referrer policy for cross-site requests, which covers the case here. So, I think we don't need extra protection here.

But we might want to have a test to ensure the protection is still working for meta refresh cases.

Sure! A patch to test the protection with meta refreshes is in revision https://phabricator.services.mozilla.com/D230033.

Note that we don't enforce the top-level navigations due to webcompat reasons.

Thanks for explaining this, I noticed that top-level cross-site refreshes can use any referrer policy, and I was previously unsure if they should be more protected than other top-level navigations.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cb57a8dd691c
Test coverage to ensure tracking protection is applied to cross-site refreshes. r=anti-tracking-reviewers,bvandersloot

Comment 6

[amarc]

https://hg.mozilla.org/mozilla-central/rev/cb57a8dd691c