Two suggestions concerning Firefox

Development HQ
1

First of all, I have to say that I hold AlmaLinux and its team in high regard for several reasons, but even Achilles has its heel and this ones is Firefox.

My first suggestion is to release new updates of Firefox much faster.

While I am very happy to see that AlmaLinux is faster than RHEL, when it comes to critical CVEs, I am disappointed to see its slowness regarding Firefox. That’s especially incomprehensible as it distributes the ESR version, which should be stable enough to ship immediately after release. I understand that there could be hindrances, when the upgrade from an old ESR to a new one occurs, but even in this case, the transitional phase should be long enough to alleviate this problem.

Firefox is the standard web browser of AlmaLinux and as an integral part of my workstation practically indispensible. During the last update cycle, it took over a week to ship the updated ESR and that is simply too long for such a critical software, which is the subject of many security vulnerabilities.

My second suggestion is to add several privacy-enhancing default preferences in the configuration file of Firefox.

This one is debatable, but I would like to see at least some of the following preferences in the configuration as Mozilla expanded its collection of telemetry data during the last years to a great extent and I think that especially users of AlmaLinux are more interested in performance and privacy than in sending masses of data to Mozilla.

I would like to propose the following preferences:

pref("app.normandy.enabled", false);
pref("app.normandy.api_url", "");
pref("app.shield.optoutstudies.enabled", false);
pref("browser.newtabpage.activity-stream.feeds.telemetry", false);
pref("browser.newtabpage.activity-stream.telemetry", false);
pref("datareporting.healthreport.uploadEnabled", false);
pref("datareporting.policy.dataSubmissionEnabled", false);
pref("datareporting.policy.dataSubmissionPolicyBypassNotification", true);
pref("dom.private-attribution.submission.enabled", false);
pref("toolkit.telemetry.unified", false);
pref("toolkit.telemetry.enabled", false);
pref("toolkit.telemetry.server", "data:,");
pref("toolkit.telemetry.archive.enabled", false);
pref("toolkit.telemetry.newProfilePing.enabled", false);
pref("toolkit.telemetry.shutdownPingSender.enabled", false);
pref("toolkit.telemetry.updatePing.enabled", false);
pref("toolkit.telemetry.bhrPing.enabled", false);
pref("toolkit.telemetry.firstShutdownPing.enabled", false);
pref("toolkit.telemetry.coverage.opt-out", true);
pref("toolkit.coverage.opt-out", true);
pref("toolkit.coverage.endpoint.base", "");
pref("browser.newtabpage.activity-stream.asrouter.userprefs.cfr.addons", false);
pref("browser.newtabpage.activity-stream.asrouter.userprefs.cfr.features", false);
pref("browser.newtabpage.activity-stream.showSponsoredTopSites", false);
pref("browser.newtabpage.activity-stream.showSponsored", false);

Greetings from Extloga!

2

Fast updates on packages is nice to have…
The question is if Alma can create something similar as Debian backport to get some packages faster, but still let the distro stay as is until a user add the repo manually… as you have to in Debian stable.
It can be good to get the firefox esr updates (and others) a bit faster as that is one of the big/primary “user-window” online when using Alma as workstation/desktop.

That was a short list. :smiley: :+1:
I’m totally in on the Privacy online thing… My Firefox has way more modified. my firefox is almost as strict as TOR browser. = less user-friendly

With that said so everyone know I’m totally all about hardening and privacy.
I think it can be a bad thing to modify Firefox package default as some people might want to have the non-privacy crap inside. LOL :rofl:
Resist fingerprint is also a good thing… but… but that break some websites…

One suggestion is that we users on this forum make a config file/list that everyone can download/copy paste to get a more privacy based version of Firefox.

But i think on default install Firefox should be untouched.

Edit:
to get faster updates… install Firefox as flatpak package. :slight_smile:

3

You do know that Alma 8 and 9 have Firefox because RHEL 8 and 9 have Firefox.

Do you also know that Red Hat left browser out from RHEL 10?
They do suggest flatpak, if RHEL 10 user needs Firefox.
How “critical” does that sound?

Do you also remember how – when CentOS 7 was on its last months and only one person did build critical packages – it took a long time to get patched Firefox for it was no easy build?

AlmaLinux 10 does provide Firefox as RPM (for convenience). That is already more than Red Hat does.

My overall take on AlmaLinux is that I get what I pay for.

4

If you use Firefox developer edition (as I do) you can update it yourself on demand from the firefox help menu item.
Instructions for RHEL/Alma/Rocky version 8.x can be found here. Dunno how it relates to versions 9 and 10 but interested to know how you get on if you do try it .

5

The default configuration of Firefox is already modified. Bookmarks and homepage are the most visible configurational changes, which are part of the AlmaLinux package. My proposed preferences are not breaking the UX in any way and users would still be able to enable telemetry and other data collection. It is practically only a change from opt-out to opt-in.

RHEL and its derivatives are LTS operating systems and therefore this will be a valid question when the previous RHEL versions are not supported anymore, but until May 2032 it is not. If this package is provided and even pre-installed, it is of utmost importance.

These quotes are from the current website of Red Hat:

Firefox is the default and only supported web browser in Red Hat Enterprise Linux.
[…]
A web browser is a very security-sensitive component and the volume of CVEs is really high (as many as 17 critical or important CVEs fixed in one update).
[…]
Mozilla provides Red Hat Development Engineering with the source code and advisories just a few days before they are made public

These sentences are underscoring the importance, which Firefox still has for Red Hat today. Furthermore, I do not see a way for a workstation, if not at least one widely supported web browser with its most recent security updates is offered.

I understand these problems, but none of the currently supported versions are even remotely comparable with CentOS 7 in its last months. If AlmaLinux 9 would need more time in 2031 or 2032 to provide these updates, I would show much more comprehension.

That is a workaround, but if I want to use only packages, which are provided by the official repositories of AlmaLinux, it is still problematic.

A hypothetical example: What if someone is installing AlmaLinux from the current ISO image and does not have a fully updated web browser after the first system update. My assumption is that this user has to use Firefox without the most recent security updates to get the necessary information and data to install the fully updated Firefox as a Flatpak.

6

Excuse me for writing two posts in a row, but I would like to bring an addendum of my observations:

This is the first time that I am actively monitoring the process of releasing the new Firefox ESR version in its corresponding repository of AlmaLinux.

The necessary sources of the current updated version of Firefox ESR (128.13.0) are in the c8s branch since 15th July 2025. This means that the possibility of testing is there since 9 days, even 7 days before the official release of this version, which occurred on the 22nd July 2025.

This update, which is not the upcoming upgrade to the new ESR series, contains fixes for at least four CVEs which are designated with the impact level “high” and according to its release notes, it does not contain any functional changes, which should be normal as it is part of the expiring ESR series.

I think that it would have been possible for AlmaLinux as well as for Red Hat to release this updated ESR version on the same day as the official Firefox release and I hope someone from the AlmaLinux team can explain this matter to me, as I do not see any blocking issues for a much earlier release.