A may-be interesting article for all those who use F-Droid:
What is your opinion? Thanks.
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.
14 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â. 
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-droidfor instance (or add a.fdroidsuffix 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 
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.