Problematic MOZ_BLOCK_PROFILE_DOWNGRADE behavior

[Mark H Weaver]

Hello IceCatters,

One annoying problem that I see with the preliminary IceCat-68 preview
is that if I switch back to an earlier version of it, upon launch I'm
*prevented* from using my existing profile.  A small modal dialog box
comes up warning me that this may damage my profile, and I'm given just
two options: (1) create a new profile, or (2) quit.  If I choose to
create a new profile, then that new profile becomes my default profile,
even after I switch back to the "newest" version of IceCat, and for many
users it will not be obvious how to recover their settings, bookmarks,
history, etc.  This is terrible, and I'd like to fix it.

The thing is, these are essentially the same versions of IceCat, except
for some minor tweaks that I'm making to fix some of the problems.  It
must be using some kind of timestamp to determine this.

On the other hand, I think it's definitely a good idea to prevent users
from running IceCat-68 on a profile that has been upgraded to IceCat-76.
I'd like to preserve the functionality that prevents downgrades from
IceCat-76 to IceCat-68 on a existing profile, while freely allowing
downgrades within IceCat-68.x, which will certainly not contain anything
that would change the profile schema.  (I can say this based on several
years of experience looking over commits on Mozilla's ESR branch for
security fixes.)

The relevant build flag is MOZ_BLOCK_PROFILE_DOWNGRADE, and if we wanted
to disable this functionality entirely, we could likely do so by setting
it to 'False' in browser/moz.configure.

The relevant code is in toolkit/xre/nsAppRunner.cpp.

Skimming the code, I'm concerned that there seems to be a lot of mention
of "telemetry" in this code, suggesting that information may be sent to
Mozilla when you downgrade.  For example, there's a function
"SubmitDowngradeTelemetry", which fetches preferences including
"toolkit.telemetry.server".  Now, we've set that preference to "" by
default in gnuzilla/data/settings.js, and "toolkit.telemetry.enabled" to
"false" by default as well, so maybe we have it covered, but it still
causes me some discomfort to see this code in here.

If someone would like to volunteer to investigate this issue further,
I'd be grateful.  Probably the first lines to look at are lines
4125-4159 in toolkit/xre/nsAppRunner.cpp.  Ideally, we would find a way
to preserve the downgrade check while making it more coarse-grained.  If
the profile was last run with a major version of IceCat newer than 68,
and now there's an attempt to run it with IceCat-68, then it's good to
block it.  However, it should not block a downgrade from IceCat-68.3 to
IceCat-68.2, and certainly not between two slightly different micro
revisions of 68.2.

As a fallback, we could simply disable this MOZ_BLOCK_PROFILE_DOWNGRADE
for now, and re-enable it some time later but well before version 68
loses upstream support, in the hopes that by the time IceCat-76 is out,
all users of IceCat-68 will be running at least IceCat-68.5, say.

Thoughts?  Volunteers?

In any case, thanks for reading this far :)

      Mark