Is it a good idea to replace the default firefox with the flatpak one?

What do you mean by that? If you’re talking about proprietary software, then Flatpak/Flathub already has a workaround for that called extra-data, which was designed to include proprietary software without redistributing. This video explains what extra-data does in practice.


Did you also uninstalled the default firefox?

No. I still have it on my system but I don’t use it at all.

I’m still using Firefox from Fedora official repository. I usually search on Flatpak when it’s not in the official repositories.

Personally, I would be glad to see Firefox removed from the OS image.

I’ve been using Firefox from Flathub since it first came out – must’ve been at least a year by now. Works completely fine for me with Wayland, WebRender, 120 Hz, and hardware accelerated video.

It might come down to your trust on the maintainers. If you would rather use a flatpak built by fedora maintainers you can add the fedora flatpak repo. Firefox in the fedora flatpak repo seems to be tracking the latest version. Some packages in the fedora flatpak repo may not be the latest but I trust the review process the in there more than the flathub ones.

That’s completely fair. However, the Firefox flatpak is entirely managed by Mozilla and built on Mozilla’s infra, so it’s essentially independent from Flathub. They only use Flathub for publishing.

1 Like

I’m thinking about switching to Firefox flatpak and I’d like to use the one on fedora. Does is still miss video codecs? In that case I’ll go with the flathub one.
Thanks for the info

It truly would boil down to either organizations approach to third party software wouldn’t it? That is the only reason to select the Fedora Flatpak repo over Flathub’s, as an example, aside from release build cycles I mean. That is why various media codec’s were forever relegated to the rpm-fusion repos, licensing. That is why the FF flatpak from Flathub works with prety much all media codecs ootb. So then the only question becomes, what is your individual licensing preference and how diligently do you apply it.

FWIW, I think that if your goal is to sandbox the browser for security,
Flatpak is not a great option. Its sandbox is too permissive.

I’ve been collecting some “recipes” for sandboxing some popular programs
with bubblewrap and seccomp-bpf filters; Firefox is one of them.

Here’s how I currently sandbox Firefox:

The first file is a C program. Compiling it and running the resulting
binary will generate a seccomp-bpf filter file.

The second file is a shell script that runs Firefox with bubblewrap; the
seccomp-bpf filter file is passed in to bubblewrap to filter syscalls.

I deliberately left out support for Pulseaudio and Pipewire; if you want
to use them, add this to the shell script:

--ro-bind /run/user/"$(id -u)"/pulse /run/user/"$(id -u)"/pulse \
--ro-bind "/run/user/$(id -u)/pipewire-0" "/run/user/$(id -u)/pipewire-0"

If you want, you can ro-bind a fake machine-id or a disposable Downloads
folder as well.


120Hz? What kind of hardware do you have? A discrete graphics card with proprietary drivers?

I have an AMD Radeon RX 550, which Firefox is running with. Regular open source drivers that are installed by default. A high refresh rate doesn’t seem especially demanding when it’s just for web browsing. (I also have an AMD Radeon 5700 XT, but that’s just being used for gaming in a Windows VM.)

I’ve verified using about:support that WebRender, hardware video acceleration, and 120 Hz are all functioning, and it’s easy to see that 120 Hz is working by doing an online frame rate test or just by seeing how smooth everything is in normal usage.

Fedora seems to apply custom patches on Firefox before publishing it on DNF repos. For example, VA-API is enabled by default just recently on the DNF version, but not the Flathub’s (you can check about:support page).

And regarding screen sharing (on Wayland): There is a bug in Flathub version where the mouse is locked to its initial position. The DNF version also had this problem, but it was like at least five versions ago. I feel it’s another patch from Fedora developers.

Also, I think being one minor version behind is not a big deal for security, as security issues mostly get fixed in bug-fix releases, not the major ones. Even in the latter case, the maintainers would ship the new version faster than normal, or generally, it gets backported to previous version(s).

Although I like the features Flatpak itself brings, I would go with the RPM, because of the extra features available in the RPM version. Or, maybe, I will continue with Fedora’s Flatpak if suitable, as I haven’t tried it yet.

Sandboxing in the Flatpak version is a little weaker, since Firefox itself can’t provision namespace-based isolation. This issue will become more significant once Firefox rolls out PID namespace isolation. I wrote about the issue more on my microblog.

You can see how Flatpak provisions sandboxes in flatpak-run.c

I also know that Mozilla has lately been tightening up Firefox’s sandboxing. They’ve recently restricted the content processes from accessing the X11 server, for instance, and have been moving much functionality to a utility process. On Windows, the utility process is further restricted by Windows’ Arbitrary Code Guard; I’ve floated the idea of emulating that on Linux the same way Edge does. All of this would need to be duplicated on the Flatpak end, and I’m not optimistic about full parity when comparing against the moving target of the browser’s own native implementation.

Personally, I think the ideal solution on Silverblue would be to install
the official auto-updating build of Firefox into a mutable directory.
That way you get the full security benefits of its sandboxing while also
not having to worry about rebooting just for a browser update.

Edit: The problem with the locked mouse is no longer available in the Flathub version and is fixed!

The Flatpak has pros and cons. It is supposed to be safer and uses Portals really well, so it doesnt need any filesystem acces (wait does it? ~/.mozilla and ~/Downloads maybe). It also has some Codecs preinstalled, that are not available on the Fedora RPM.

Cons are, that KeepassXC-browser and KDE-Connect / Plasma integration are not working out of the box. These communications can be fixed, but its quite an efford. I will try to integrate that into the “Fedora OSTree setup script”, together with the changed one for KDEConnect, but its complicated and may not work.

This is really poor, as

I’ve found an excellent way to manage extensions is GNOME Extension Manager (not to be confused with GNOME Extensions):

Since I installed that I’ve not had to deal with the web site at all.