Should you use a fork?

Privacy Questions
1

Are forks of software recommended? Can they be more private and secure than the upstream project? Even with delayed updates?

Curious to hear your thoughts on this.

Examples I can think of are LibreWolf, Moshidon, Signal-FOSS, etc.

2

Fork being late is not a universal thing, do remember that ubuntu is a debian fork

And not everything is time/security sensitive with updates, I use a newpipe fork that’s delayed by days or maybe a week. And it works just fine

1 Like
3

Your examples are all forks that actually have an upstream that they’re actively tracking. That isn’t true in general for a fork.

If I assume your question is just contrained to that specific kind of fork, then my answer would be that it still depends on many things. Quality of distribution binaries for your specific system / packaging, timeliness of updates (2-3 days vs 2-3 weeks vs 2-3 months can make a big difference depending on the kind of software and your needs), usefulness of the additional features of the fork (might just be some redudant additions, or might be very useful to you), etc.

2 Likes
4

I’d say it depends on how much value the fork actually adds and what the risks are of using it, as well as how quick they’re able to keep up with upstream updates.

For instance, GrapheneOS, despite being a fork of AOSP, adds a massive amount of value to Android in terms of improving privacy/security, etc, and its able to update super quickly, so in that case, I’d say its definitely worth it.

Another example would be like Mull or Brave. Mull removes proprietary blobs from Firefox upstream and has a very nice privacy configuration, while also keeping very quick updates, so in my eyes I see it as worth using. Same with Brave, despite being a Chromium fork, it adds a lot of important and useful privacy features, while also having a good track record with updates.

On the other hand, forks like Librewolf and Signal-FOSS that you mentioned are harder to justify using IMO. Librewolf’s biggest feature is really just the preferences it sets, and a couple UI changes. It doesn’t add much to actually justify using it and adding another trusted party/potentially delayed updates vs. just using and tweaking Firefox directly. Signal-FOSS also seems to have delayed updates and its changes don’t seem major enough to justify, since all it does is remove using GMS for notifications (which can be done in regular Signal anyways), and using OSM instead of Google Maps for location sharing (which I don’t use and doubt most people do use as well). Some of its tweaks are nice to have, but just not sure able to justify using a fork over and losing out on quicker updates.

So it really just depends. Take it on a case by case basis, look through the pros and cons, and determine what works best for you and your threat model, to see if its really worth using a fork or not. It just depends on your needs.

3 Likes
5

I think this is too broad of a question to be answerable or useful without further specificity, because (1) “Fork” is a broad concept, there are really substantial differences within the umbrella of ‘forks’ (e.g. soft fork or hard fork, etc), and (2) the details and context matter a lot, the type of product/service, relationship to the upstream (forked) project, type of fork, reputation and size of the team of the forked project, why was the project forked?

As a general rule I tend to prefer sticking with the larger upstream version if there is no compelling reason to switch. Because the larger upstream project is usually more established, with a longer and more public history, larger team of contributors, and developers with knowledge of the original design model of the software. Of course there are nearly as many exceptions to this rule of mine as not. There are many many cases where I prefer the fork to the original or mainline project for a variety of reasons. Basically I care less whether something is a fork or not and more about the health, size, reputation, and durability/longevity of the project.

1 Like
6

Regarding updates, I keep historical dates here:

Regarding desktop browser forks, ain’t no need to fork when you can just use your distro Firefox/Chromium with largely version-agnostic configs through eg. my Brace: divested/brace: Toolkit compatible with multiple Linux distros that allows for installation of handpicked applications, along with corresponding configs that have been tuned for reasonable privacy and security. - brace - Codeberg.org

5 Likes
7

First of, forks are the entire point of having things open sourced.

What matters more is who is maintaining the forked software. If you forked it yourself, you are entirely responsible for the software. If you are using someone else’s fork, it entirely becomes a different software and you are shifting the responsibility to the maintainers of the this new software. The usual caveats apply: are the patches applied reasonably timely? If so, it should be fine. This is particularly important for things that are actively prodded upon the internet like web browsers and operating systems.

For less important/critical things like, say a fork of GIMP, it should be generally fine to use a fork.

Also, its hard to use a knife and spoon and you usually need to use a fork.

2 Likes
8

This is where you use chopsticks

1 Like