Hi Rosika,
I believe you download the latest version, unpack it, and install it.
Waterfox has changed hands again, back to the original developer.
Have a look, some distros now have it in their repository … that would allow an easier install and automatic updates. I know Artix and Antix have it.
I must check myself. Mine is out of date..
Regards
Neville
Meanwhile, I create my own waterfox.deb and deploy it to my own apt-repo server. But whenever it comes to LMDE, I’ll drop it and use the official one.
What tool do you use for that?.. or do you make it by hand?
I extracted the tarball, same as I would for manual installations. Then I supplied the additional stuff required for a package (control file, etc.). Finally, the package is created by a tool named dpkg-deb.
@nevj :
Hi Neville, 
Right. Well, for me the installation process was a bit more difficult, but manageable. That´s because I need to run waterfox in a firejail sandbox.
Here´s how I did it:
Download and extract the tar.bz2 file
sudo cp -r /media/rosika/f14a27c2-0b49-4607-94ea-2e56bbf76fe1/DATEN-PARTITION/Dokumente/Ergänzungen_zu_Programmen/zu_waterfox/waterfox /opt/waterfox # that´s meant as an example. It´s the path where my extracted waterfox folder currently resides
sudo ln -sf /opt/waterfox/waterfox /usr/local/bin/waterfox # I updated the symlink as I had already one residing in /opt. It was a leftover from my previous experiments.
Now I can run waterfox normally in the terminal.
firejail --private=/media/rosika/f14a27c2-0b49-4607-94ea-2e56bbf76fe1/DATEN-PARTITION/Dokumente/work6 waterfox # Run Waterfox sandboxed with a private home.
--private=... keeps all user data in a dedicated folder.
Firejail now uses the official waterfox.profile. Nice. 
Note:
Since /opt is a trusted system path, firejail finds the binary without errors.
That was the initial problem I had to overcome.
First I tried to tweak waterfox.profile by whitelisting some paths etc, but it wouldn´t work.
It turned out the issue isn’t just a profile tweak.
Firejail is very strict about executables outside standard system paths.
Even with whitelist and private-bin, firejail couldn´t find binaries that live on any desired mounted partitions (like my /media/... data partition) because it performs checks at startup to ensure the binary is “trusted” and accessible.
I had to do quite some research to find that out.
So the installation method I just described worked well for me.
/opt to the rescue.
It provides me with a high-security instance of waterfox running in firejail using a dedicated home directory.
Many greetings from Rosika 
The only thing left is getting a trigger when a new download is available to invoke the download and my build process. But I can live with it for now.
Hi Rosika,
There is good reason for that. Untrusted binaries are malware waiting to happen.
Programmers compiling stuff and making their own binaries are regarded as security hazards by system admin types.
Do you have a list of trusted system paths?
Is /opt regarded as somewhere outside the package system but still trusted?
Regards
Neville
Thanks, I have unpacked a .deb file , to install stuff by hand, but I have never built one.
Hi Neville,
You’re absolutely right: firejail is strict about where it allows executables to run from, and that’s intentional to block untrusted or potentially tampered binaries.
My research led me to the following:
The “trusted system paths” firejail recognizes are the usual root-owned locations, for example:
/bin, /usr/bin, /usr/local/bin
/sbin, /usr/sbin
/usr/lib*, /usr/local/lib*
/opt
Directories like /home, /media, or /mnt are not trusted because they can be modified by regular users or reside on removable drives.
So yes : /opt is a bit special: it sits outside the package manager but is still considered a trusted system directory.
That’s why placing waterfox in /opt worked, while running it from /media/... failed.
Cheers from Rosika
Hi Rosika,
So if /usr/local/bin is trusted, why did firejail need the link to /opt?
Thank you for the info.
Regards
Neville
Hi Neville,
Ah, good question.
firejail needed waterfox to actually live in /opt, because that’s a trusted system-owned path.
If the binary had stayed in /media/..., Firejail would have rejected it as untrusted (removable/user-writable).
The symlink in /usr/local/bin wasn’t about trust, but convenience:
it just puts Waterfox on my $PATH, so I can type waterfox instead of the full /opt/waterfox/waterfox.
So: /opt gave me trust, /usr/local/bin gave me usability.
Hope it helps.
Cheers from Rosika
P.S.:
without the symlink I’d have to launch it like this:
/opt/waterfox/waterfox
With the symlink in /usr/local/bin, I can just run:
waterfox
If you check with:
which waterfox
you’ll see it resolves to /usr/local/bin/waterfox, which is only a shortcut pointing to the real binary in /opt.
ll /usr/local/bin
[...]
lrwxrwxrwx 1 root root 22 Sep 9 16:59 waterfox -> /opt/waterfox/waterfox
[...]
Hi Rosika,
So, alternatively you could have put /opt in your path?
Sorry, I missed the /media bit.
Regards
Neville
Hi Neville,
Yes, adding /opt to the $PATH should work in principle.
However, I prefer to keep third-party apps organized in their own subdirectories (e.g., /opt/waterfox/) rather than dumping everything directly in /opt.
The symlink in /usr/local/bin is just a convenience: it allows me to run waterfox anywhere without typing the full path, while keeping /opt neat and organized.
So /opt stays the trusted location, and /usr/local/bin gives me a simple command.
Many greetings from Rosika