Closed Bug 1720294 Opened 5 months ago Closed 4 months ago

Ignoring referrer policies 'unsafe-url', 'no-referrer-when-downgrade' and 'origin-when-cross-origin'

Categories

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

task

Tracking

()

RESOLVED FIXED
92 Branch
Tracking Status
firefox92 --- fixed

People

(Reporter: timhuang, Assigned: timhuang)

References

(Blocks 1 open bug)

Details

Attachments

(4 files)

We will add a pref 'network.http.referer.disallowRelexingDefault' to control if we want to ignore these referrer policies.

More details about this can be found in here.

Add a pref to control if Firefox to disallow relaxing the referrer
policy. If it's set, we will ignore 'unsafe-url',
'no-referrer-when-downgrade' and 'origin-when-cross-origin'.

We will ignore these referrer policies and treat them as the default
referrer policy.

Depends on D119971

Attachment #9231344 - Attachment description: Bug 1720294 - Part 1: Add a pref 'network.http.referer.disallowRelexingDefault'. r?ckerschb → Bug 1720294 - Part 1: Add a pref 'network.http.referer.disallowCrossSiteRelexingDefault'. r?ckerschb
Attachment #9231345 - Attachment description: Bug 1720294 - Part 2: Ignore referrer policies 'unsafe-url', 'no_referrer_when_downgrade' and 'origin_when_cross_origin'. r?ckerschb → Bug 1720294 - Part 2: Ignore less restricted referrer policies for cross-site channels. r?ckerschb
Attachment #9231346 - Attachment description: Bug 1720294 - Part 3: Flip off 'network.http.referer.disallowRelaxingDefault' for tests. r?ckerschb → Bug 1720294 - Part 3: Flip off 'network.http.referer.disallowCrossSiteRelaxingDefault' for tests. r?ckerschb
Pushed by tihuang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4ddb82c5ddbb
Part 1: Add a pref 'network.http.referer.disallowCrossSiteRelexingDefault'. r=ckerschb
https://hg.mozilla.org/integration/autoland/rev/c67383d1e9b4
Part 2: Ignore less restricted referrer policies for cross-site channels. r=ckerschb
https://hg.mozilla.org/integration/autoland/rev/39bf9fa63735
Part 3: Flip off 'network.http.referer.disallowCrossSiteRelaxingDefault' for tests. r=ckerschb
https://hg.mozilla.org/integration/autoland/rev/ae9c13cd6143
Part 4: Add tests for disallowing relaxing default referrer policy. r=ckerschb

Hi, those changes(or related) completely broke our dev-env code using cross-server communication in one place.
We use <a referrerpolicy="no-referrer-when-downgrade" href="https://other-server/..." ...

While searching for the issue I've scanned multiple nightly versions, and then by manual lookup of commits came across one leading to this ticket:

25/07 - Works
28/07 - Works
29/07 Morning(09:36:15) - Works -> 55840ec461aa5df937c71d50f2c98b93af365b6d
29/07 Evening(Last) - Bad -> 027aeb3ebc746a154d9b60f8e2e9d4cb538eede5
30/07 - Bad
01/08 - Bad

This one has two problems:

  1. network.http.referer.disallowCrossSiteRelexingDefault doesn't work at all(Tried both false and true with browser restarts) - Referrer not passed correctly(Only origin instead of full URL)
  2. Then ETP is off for the site(I turned ETP off for both main server and the cross-site server) this still doesn't work and gets blocked, while this issue assigned to Anti-Tracking, so shall not block anything w/o ETP.

I've forced to hold Chromium window open for our deployments now because FF completely broke everything out with this.

Thanks for the feedback!

(In reply to vityan888 from comment #8)

Hi, those changes(or related) completely broke our dev-env code using cross-server communication in one place.
We use <a referrerpolicy="no-referrer-when-downgrade" href="https://other-server/..." ...

Can you share further details about your application? Is it publicly hosted somewhere?

  1. network.http.referer.disallowCrossSiteRelexingDefault doesn't work at all(Tried both false and true with browser restarts) - Referrer not passed correctly(Only origin instead of full URL)

There's a typo in the commit message but not in the code, so the correct pref name is network.http.referer.disallowCrossSiteRelaxingDefault

  1. Then ETP is off for the site(I turned ETP off for both main server and the cross-site server) this still doesn't work and gets blocked, while this issue assigned to Anti-Tracking, so shall not block anything w/o ETP.

Not necessarily, there's no clear rule for what goes into the ETP toggle and we consider some privacy work base-line web platform improvements, especially if they're shared with other browser vendors. In this particular case it's also difficult to know which site the user should use the toggle on, the referrer or the target?

<q>Can you share further details about your application? Is it publicly hosted somewhere?</q>
It's private app.
In short we have two hosts(With LAN addresses), one is git and PR management system, and second one is smaller tool for code deployments, located on another server. We have a button in UI of git management which opens tab of delivery management, which uses referrer, to read the URL of git management system, which is PR link, and thus knows which PR needs to be deployed, then manages everything via API.

<q>There's a typo in the commit message but not in the code</q>
Oh my... Because it allowed to create a new value I didn't notice its a wrong one. Tested with proper value and it works now, then set to 'true'. Thx.
However, it took time to find it and it's still internal config. No ETP relation or setting for Privacy tab for it.

<q>Not necessarily, there's no clear rule for what goes into the ETP toggle</q>
Sure, but if both domains are toggled off?

Also does this really add any privacy enhancement? I think I can pass the original url via JS the same way, it's just dirty and referrer works much cleaner in our case.

Thanks! Glad that you figured out the pref.

Also does this really add any privacy enhancement? I think I can pass the original url via JS the same way, it's just dirty and referrer works much cleaner in our case.

Passing the URL as a parameter makes it explicitly visible to the user (and the user agent) and requires a larger amount of cooperation on the target page. If this fixes your issue I would indeed recommend you to do that.

However, we talked about this internally and agree that we should try to integrate with the ETP toggle. We’ll file a follow-up bug for that.

[q]However, we talked about this internally and agree that we should try to integrate with the ETP toggle.[/q]
This is great. Thanks again.

You need to log in before you can comment on or make changes to this bug.