1599188 - hardcode ESR version because ESR doesn't ship every 8 releases anymore

Status: RESOLVED FIXED

(Core :: DOM: Security, task, P3)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://docs.google.com/spreadsheets/d/1QAbF2mM-v7usT8hrNIAnaz7ybDaRzPR-YfN_8sxWGhc/edit#gid=327015013 has the upcoming ESR versions: 78 and 91 after the current 68. In other words: The current ESR release cannot be calculated anymore unless the release of an ESR version gets bound to a specific date in the year.

Making the latest ESR version directly available to the application looks less error prone if changing it becomes of the 'new ESR' playbook.

The two current calculations of the ESR version I found:
https://hg.mozilla.org/mozilla-central/annotate/d39f4366eba4bf1b89f0f3a48ace2d8c9e1f410f/browser/components/resistfingerprinting/test/browser/browser_navigator.js#l253
https://hg.mozilla.org/mozilla-central/annotate/d39f4366eba4bf1b89f0f3a48ace2d8c9e1f410f/toolkit/components/resistfingerprinting/nsRFPService.cpp#l655

Comment 1

[Daniel Veditz [:dveditz]]

This is arguably wrong, but perhaps not terrible since all the "resistFingerprinting" folks will consistently report the same version, which is sort of the point. But better if that can hide in the small ESR crowd so worth fixing.

Comment 2

[Chris Peterson [:cpeterson]]

I believe Release Management is aiming to have one major ESR release a year. (ESR 78 and 91 release dates are both scheduled for the end of June.) If we maintain that cadence, there would be a new ESR major version every 12 or 13 Firefox releases.

I suggest we change the ESR version spoofing algorithm to assume we have a new ESR every 13 releases (i.e. 91 - 78 = 13):

• If current version < 78, then spoof version 68 (the current ESR version).
• If current version >= 78, then assume ESR version to be spoofed is 78 + 13 * X.

https://searchfox.org/mozilla-central/rev/8bc24752246aeac8a9aed566cf1caccf88d97d11/toolkit/components/resistfingerprinting/nsRFPService.cpp#683-686

If this algorithm is wrong, we'll won't need to worry about it until ESR 104±1 in 2022. :) We already have debug asserts to catch if the spoofed version no longer matches the ESR cadence:

https://searchfox.org/mozilla-central/rev/8bc24752246aeac8a9aed566cf1caccf88d97d11/toolkit/components/resistfingerprinting/nsRFPService.cpp#673-681

Comment 3

[Chris Peterson [:cpeterson]]

I have a patch to fix this bug. I will post it for review when the 78 Nightly cycle starts.

Comment 4

[Chris Peterson [:cpeterson]]

Attachment: Bug 1599188 - Update ESR version spoofing calculation to assume a new ESR is released every June. r?ethan

The old ESR version calculation assumed six-week release cycles, but Firefox has moved to four-week release cycles and Release Management shifted some of the ESR dates.

I plan to remove the special case for Firefox version < 78 once the 78 Nightly development cycle starts.

Comment 5

[Ethan Tseng [:ethan]]

Can we set bug 1583326 as resolved duplicate of this one?

Comment 6

[Chris Peterson [:cpeterson]]

(In reply to Ethan Tseng [:ethan] from comment #5)

Can we set bug 1583326 as resolved duplicate of this one?

Yes. I'll dupe that bug.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/79814e338266
Update ESR version spoofing calculation to assume a new ESR is released every June. r=ethan,timhuang

Comment 9

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/79814e338266