Closed Bug 1806690 Opened 2 years ago Closed 9 months ago

Remove the frozen `rv:109.0` IE11 UA workaround after Firefox reaches version 120 (desktop and Android)

Categories

(Core :: Networking: HTTP, task, P3)

task

Tracking

()

RESOLVED FIXED
120 Branch
Tracking Status
firefox-esr115 --- wontfix
firefox118 --- wontfix
firefox119 --- wontfix
firefox120 --- fixed

People

(Reporter: cpeterson, Assigned: cpeterson)

References

Details

(Whiteboard: [necko-triaged])

Attachments

(2 files)

Bug 1805967 froze the UA's rv: token to version 109 to avoid webcompat problems where websites mistook Firefox 110's rv:110 as IE11's rv:11. Once Firefox reaches version 120, we can remove the workaround and continue to report rv:120+.

The Nightly 120 release cycle will start on 2023-09-25. See you then!

Component: Interventions → Networking: HTTP
Product: Web Compatibility → Core
Target Milestone: --- → Future
Assignee: nobody → cpeterson
Whiteboard: [reminder-test 2023-09-25]

FYI: Bug 1805967 was desktop, Bug 1806675 was gecko android .. see you in September

Chris, how does the current state affect the android version with RFP when it hits the next ESR number: something to check when we get there for our annual manual patch

Whiteboard: [reminder-test 2023-09-25] → [reminder-test 2023-09-25][necko-triaged]

(In reply to Simon Mainey from comment #1)

Chris, how does the current state affect the android version with RFP when it hits the next ESR number: something to check when we get there for our annual manual patch

Firefox Android's version with RFP is unchanged and not a problem because it's hard coded to return version 102, desktop's current ESR version (though desktop RFP no longer returns the ESR version: bug 1769022):

https://searchfox.org/mozilla-central/rev/664e09d9df713177b233f21a3af177e85796c2f0/toolkit/components/resistfingerprinting/nsRFPService.cpp#576

Blocks: 1806675
Summary: Remove the frozen `rv:109.0` IE11 UA workaround after Firefox reaches version 120 → Remove the frozen `rv:109.0` IE11 UA workaround after Firefox reaches version 120 (desktop and Android)
Duplicate of this bug: 1817530
No longer duplicate of this bug: 1817530

9 months ago, cpeterson placed a reminder on the bug using the whiteboard tag [reminder-test 2023-09-25] .

cpeterson, please refer to the original comment to better understand the reason for the reminder.

Flags: needinfo?(cpeterson)
Whiteboard: [reminder-test 2023-09-25][necko-triaged] → [necko-triaged]
Flags: needinfo?(cpeterson)

(In reply to richard (Tor Project) from bug 1818889 comment #7)

it's too early to tell whether we will stick with this ESR-based android after the 115 transition. Backporting security issue fixes to 102 this past year has been mostly painless and not terribly time consuming compared to auditing the new rapid-release track merged changes each month which we fell behind on between 91 and 102.

Richard, do you have any news since bug 1818889 comment #7 (in April 2023) about whether you will continue to backport Android TB security fixes to ESR 115 or might switch to Firefox Android's monthly rapid releases?

Now that Firefox Nightly has reached version rv:120.0, I have a patch to remove the rv:109.0 UA workaround (to fix sites that mistake rv:110.0 - rv:119.0 as IE11's rv:11).

Should I keep the RFP code that spoofs version Firefox/115.0 (and thus requires rv:109.0) on Android rapid releases with version >= 120?

https://searchfox.org/mozilla-central/rev/37d9d6f0a77147292a87ab2d7f5906a62644f455/toolkit/components/resistfingerprinting/nsRFPService.cpp#803-808,847-852

I must admit I still don't understand why Android RFP spoofs ESR version 115 when its Gecko version is > 115. Nearly all Firefox Android users have the latest version (thanks to the Google Play Store's auto-updates), so Android TB and RFP users that spoof ESR version 115 aren't hiding in a crowd: instead, they're a small user population that is effectively identifying themselves as TB and RFP users. I don't know if that is a concern or if there is some other benefit of Android TB spoofing ESR version 115.

Flags: needinfo?(richard)

I must admit I still don't understand why Android RFP spoofs ESR

see https://bugzilla.mozilla.org/show_bug.cgi?id=1769022#c23 and comments around it.

We spoof android as ESR in RFP, but since TB ships an updated ESR version for android, it is not actually used. Instead, only RFP Firefox android users get this behavior, and without wanting to put words in richard's mouth - it was kept that way should Tor Project wish to revert to rapid/stable release on android. Personally, I think we could drop the version spoofing everywhere. You can't hide the version with JS (feature detection is very cheap, performant, easy and 100% foolproof, i.e not reliant on prefs)

(In reply to Chris Peterson [:cpeterson] from comment #5)

(In reply to richard (Tor Project) from bug 1818889 comment #7)

it's too early to tell whether we will stick with this ESR-based android after the 115 transition. Backporting security issue fixes to 102 this past year has been mostly painless and not terribly time consuming compared to auditing the new rapid-release track merged changes each month which we fell behind on between 91 and 102.

Richard, do you have any news since bug 1818889 comment #7 (in April 2023) about whether you will continue to backport Android TB security fixes to ESR 115 or might switch to Firefox Android's monthly rapid releases?

Now that Firefox Nightly has reached version rv:120.0, I have a patch to remove the rv:109.0 UA workaround (to fix sites that mistake rv:110.0 - rv:119.0 as IE11's rv:11).

Should I keep the RFP code that spoofs version Firefox/115.0 (and thus requires rv:109.0) on Android rapid releases with version >= 120?

https://searchfox.org/mozilla-central/rev/37d9d6f0a77147292a87ab2d7f5906a62644f455/toolkit/components/resistfingerprinting/nsRFPService.cpp#803-808,847-852

I must admit I still don't understand why Android RFP spoofs ESR version 115 when its Gecko version is > 115. Nearly all Firefox Android users have the latest version (thanks to the Google Play Store's auto-updates), so Android TB and RFP users that spoof ESR version 115 aren't hiding in a crowd: instead, they're a small user population that is effectively identifying themselves as TB and RFP users. I don't know if that is a concern or if there is some other benefit of Android TB spoofing ESR version 115.

We are going to continue backporting the anroid-specific security issues to ESR 115 through thorugh at least this ESR-cycle. We will re-evaluate next summe.

Flags: needinfo?(richard)

We are going to continue backporting the anroid-specific security issues to ESR 115 through thorugh at least this ESR-cycle. We will re-evaluate next summe.

Thanks. That's good to know. While I'm modifying this code to remove the rv:109.0 workaround, I think I will also remove RFP's special case to spoof the ESR version on Android. IIUC, this special case won't be necessary because:

  • If you stick with ESR next year, then Android TB's version will already be the ESR version.
  • If you switch from ESR 115 to the rapid releases next year, I assume you will want Android TB to use the rapid release version.

It's now! 120 is now! Should we do this? :-)

Flags: needinfo?(cpeterson)

(In reply to :Gijs (he/him) from comment #9)

It's now! 120 is now! Should we do this? :-)

Yep! I have a local patch. I just need to incorporate Richard's feedback about the Android UA.

I should have prepared this patch to land on day 1 of the 120 Nightly cycle, so we would get more pre-release testing of webcompat breakage. If you think that's a concern, I can just wait until the 121 Nightly cycle. I think the webcompat risk is low, but there's no need to rush this change.

Flags: needinfo?(cpeterson)
Target Milestone: Future → 120 Branch

(In reply to Chris Peterson [:cpeterson] from comment #10)

(In reply to :Gijs (he/him) from comment #9)

It's now! 120 is now! Should we do this? :-)

Yep! I have a local patch. I just need to incorporate Richard's feedback about the Android UA.

I should have prepared this patch to land on day 1 of the 120 Nightly cycle, so we would get more pre-release testing of webcompat breakage. If you think that's a concern, I can just wait until the 121 Nightly cycle. I think the webcompat risk is low, but there's no need to rush this change.

I think we've found the frozen 109 thing has also caused issues, so I'd err on the side of 120 and back it out if we hit issues. If you're very worried, IIRC we used a pref so we could keep that initially and just set it to 120 atm (across the board) and then properly remove for 121?

Tor Browser (TB) currently ships Android builds built from the ESR 115 branch. This RFP special case to spoof the ESR 115 version on Android was kept in case TB decided to switch to non-ESR Android rapid releases and keep the same 115 version.

This special case is no longer necessary:

  • If Android TB sticks with ESR next year, Android TB's version will already be the new ESR version.

  • If TB switches from ESR to the rapid releases, Android TB should use the rapid release version because that's the version nearly all other Firefox Android users' UAs report.

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

Attachment

General

Created:
Updated:
Size: