What about F-Droid?

A may-be interesting article for all those who use F-Droid:

What is your opinion? Thanks.

1 Like

use f-droid and will continue to do so

2 Likes

I’m a big supporter of weakening Android’s security model but I don’t think using sources other than what Google tells you you’re allowed to use does that.

Slow updates and complaints about the API level don’t really matter to most users and I disagree that using multiple repositories constitutes a lack of good practices - it’s a widely accepted practice on many platforms. So the remaining substantive argument of the article is that the code is checked only at a very basic level - which would be true if you didn’t take community vetting into account, which is more or less the entire point of libre software. I trust F-Droid software not because it comes from F-Droid, but because it comes from communities of devs who dedicate themselves to writing good code and who check one another’s work constantly.

All in all, that feels a lot safer to me than closed-source apps that force me to rely on Google - Google, who tell me not to concern myself with my own safety, also no one is allowed to look at the code, but they promise it’s safe.

13 Likes

F-droid apps are without trackers, backdoors and ads. The F-droid app is like apt on Debian. I’ve never had a smartphone without it & I only entered the f-droid archive and the guardian project archive as sources. I love that I have direct contact with the respective app developers on github or gitlab.
By the way: For about 30 years I’ve only had community developed OS and software on all workstations, servers, network devices and laptops. And I enjoy the freedom and security.
Fun Facts: On a Huawei device you have to trust the official Huawei app store ‘AppGallery’. :laughing:

5 Likes

Thanks for this, it clarifies. The article in question has been spread via Twitter in some Fairphone bubbles yesterday.

The issue with F-Droid is that all apps are signed by the same party (F-Droid) which is also not the developer. You’re now adding another party you’ll have to trust since you still have to trust the developer anyway, which isn’t ideal: the fewer parties, the better. (The trusted party problem)

This is an oversimplification. After all, it implies the .apks the developer distributes always match the source code and there’s no hidden changes. Even if you trust the developer, most developers build apps on the same laptop they run all other kinds of untrusted software on and could get infected with malware. F-Droid builds apps from source (like Debian and the likes) just to know for sure the .apk matches the source code. It can be signed with the developer’s key if the developer’s .apk matches the one built by F-Droid (but sadly most developers don’t opt in to this option).

Considering all this, and the fact that their build process is often broken using outdated tools, you have to expect far slower updates compared to a traditional distribution system. (Slow and irregular updates)

On average it takes about 3 to 5 days for a new released tagged by a developer to end up distributed to users on F-Droid. I have had several Google Play reviews delay my app updates for longer. Yes, there are some outliers sometimes, but generally from my experience of publishing an app to both F-Droid and Google Play… there really isn’t much of a difference.

Low target API level (SDK) for client & apps

For F-Droid itself, yes, this is known and there are open GitLab issues on improving it. F-Droid is a small team and these things take time. It could be sped up if people would make merge requests to help do some of the work.

For apps, I just don’t agree it’s helping anyone to remove apps not targeting the latest targetSdk as harshly as Google does as it’ll do nothing but push people towards apps ran by big companies that sell user data (as they have the budget and time to keep everything 100% up-to-date).

General lack of good practices

There are a few points here and there that indeed call for improvements, and as far as I know all the valid points here have GitLab issues tracking them.

F-Droid should enforce the approach of prefixing the package name of their alternate builds with org.f-droid for instance (or add a .fdroid suffix as some already have). Building and signing while reusing the package name (application ID) is bad practice as it causes signature verification errors when some users try to update/install these apps from other sources, even directly from the developer. (Confusing UX)

I find this a double standard, as Google doesn’t even allow developers to use their own signing key anymore. Why isn’t Google being called out here? F-Droid supports this and F-Droid also allows developers to use a custom package name (which some F-Droid packages do)

Misleading permissions approach

I don’t really have much to say but I don’t really think Google Play does this better? Don’t know.

Should I really care?
It’s up to your threat model

This is the most important point in the entire article. Most of the points raised are really minor points in the grand scheme of things.

14 Likes

The author is

a random guy passing by on the Internet who is interested in all kinds of things.
And as you can tell, I’m a nerd.

(from About | Wonder's Lab)

So it is just another opinion on Android security. I read a lot of “could” and “should” in his article and as far as I know reality is that there are more threats in the Play Store than in F-Droid.

That makes sense as there is more in the play store :slight_smile: