I was really looking forward to something like F-Droid on iOS after the DSA came into force, but unfortunately Apple’s absurdly bad compliance has rendered such a thing all but impossible.
While F-Droid may be important, I personally tend to prefer Aurora Store and even more Obtainium[1]. Although you have to be even more careful what you install, Obtainium is extremely good at keeping apps up to date.
Some projects don't even provide an F-Droid release, so just adding the github repository to Obtainium is much easier than having to deal with apk stuff.
The Aurora Store app is just a frontend for the play store. It's a useful tool, but gives none of the benefits the existence of F-Droid provides to the world. Obtainium just fetches an .apk from a site, also useful, but provides none of the security aspects of F-Droid or the Play Store.
There is no good alternative to F-Droid. Thankfully that's just because it is such a great concept.
hey HEY!
fdroid all the way!
I do the web sight sign in every time!
java cookies dom get switched on selectivly
de google till it breaks and then factory reset
and try again
linux laptop and adb keeps my pics and files,
move them to a thumb drive once in a while
I almost never see any adds and can do all the
"things" just fine
but like the article says,you gota be brave
I use android and my first place to look for apps is fdroid. It doesn't have the best search and it doesn't have many apps. But I have hit the jackpot on a few apps and that's more than enough to justify its existence for me.
It's particularly good for very niche use cases, like, you might need an app that simulates dice rolls, then fdroid might be the best place for that as you'll find an app that does just that and nothing else. No ads, no bullshit.
If fdroid doesn't work for me then I will give in and search for "commercial" (ads or paid) solutions.
My understanding is that this largely stems from the fact that F-Droid compiles and signs all the apps on behalf of the application developers, so there is a loss of control there. Some will say that this is what redistributable builds are for, but in my experience they are not actively/widely verified even if they do support it, especially publicly.
Privacyguides isn't very good in my experience. It's got a real "blind leading the blind" thing going on, where a bunch of half-truths are repeated ad-nauseam because at some point, someone told them that thing X is bad for your privacy. It's probably best exemplified in how they can't seem to stop recommending Brave, even though you're probably better off just loading up literally any other browser that isn't Google Chrome with privacy extensions instead.
Practically speaking, you should just assess the following threat model; which is going to be a greater threat to you:
* The F-Droid servers, where the most realistic threat is a rogue actor obtaining the keys.
That second one is also mitigated by the fact that F-Droid generally prefers to practice "reproducible signing"; basically they'll distribute the developers apk, not the one on F-Droids buildserver, if the F-Droid release matches the GitHub release (minus the signature obviously), making the signature problem mostly a non-issue.
For most people, I'd argue the former (a "surprise update" to insert anti-features[0]) is a greater risk than the latter, so F-Droids model fits them better. The sole exception would be extremely privacy sensitive apps where trusting the developer is more paramount than having the second man in-the-middle that F-Droids maintainers are. (A basic example of that would probably be Signal.)
[0]: As defined here, although not all are relevant for users: https://f-droid.org/docs/Anti-Features/ , although I'd just add de facto adding pointless microtransactions and subscriptions to this list. They're just not included since F-Droid wouldn't ship them.
This is part of the longstanding devs vs. distros tug of war. There is a loss of control for the devs, but it's better for the user to have distros like F-Droid. The alleged security benefits feel paternalistic, like the dev knows best so only they should be able to sign binaries. Why someone would get into FOSS development and then get upset when someone exercises their rights to build from source and distribute binaries is baffling to me.
> Why someone would get into FOSS development and then get upset when someone exercises their rights to build from source and distribute binaries is baffling to me.
This happens at an alarming rate within the video game emulation community. Many projects (including MAME) have openly expressed deep disdain for any forks existing at all. It's like they think any difference a fork has is a negative thing and then aggressively attack that... as if there is only one way to write software. Some projects have even stopped upstream development entirely, or closed the source or changed their license... just over forks. License violations (including GPL as well as non-commercial ones) are also rampant there.
> F-Droid compiles and signs all the apps on behalf of the application developers
At least they are open and honest about it. As opposite to Google, who promised to let developers do the signing, but soon (after gaining worldwide popularity) took over with extremely shoddy justification.
Yes and it is often a source of contention as well, not only for those same reasons but also others. For example, package maintainers often configure the programs differently (see: keepassxc drama) and often the users expect support from the upstream for problems they have no control over, sometimes even causing the upstream to stop development entirely due to the entitlement and abuse of downstream users.
Do these same concerns still pertain to dev-hosted F-Droid repos? (E.g. I am thinking of how I install Bitwarden from the their own repo: https://mobileapp.bitwarden.com/fdroid/)
IMHO, one of the best parts about the F-Droid ecosystem is its openness. Security models are not a one-size-fits-all and it is important to me to have access to software from multiple sources.
I say that possibility is canceled out because those layers of protection also provide avenues for additional bad actors and even more possibility of places to inject malware/compromises.
They might provide additional avenues, but they remove others, so it's hard to assess what's safer (I'd lean towards F-Droid-like solutions).
The best of both worlds is where both the developer and a third party certify the builds, as happens with F-Droid's reproducible builds.
On Android you're still left on deciding whose signature to put on the binary, however (I'd prefer one from the third party, differently from what happens with F-Droid reproducible builds).
It would be nice if both parties could sign the binary. My biggest issue with reproducible builds is that not every project supports it, and many that do aren't being verified (like Signal).
I was more referring to supply chain attacks and intentional backdoors, which have happened multiple times in the past. Debian servers have also been hacked before.
Except for some apps for financial institutions, all my apps come from F-Droid. I feel like I can trust their vetting but absolutely cannot trust random apps from Google's store. Why is it that unpaid volunteers can do better than one of the largest tech corps on the planet? Google is pathetic.
There's no overwhelming financial incentive in open-source applications, while both mobile stores are a constant arms race in monetization, advertisement and shady practices, where legitimate and privacy respecting alternatives are relegated to obscurity and difficult to find even if you're specifically looking for them by name. In some ways FOSS software is even discouraged from being published due to some rules (see for example donation links being strictly forbidden) and the probability of fake malicious apps, like NewPipe or SimpleMobileTools clones.
Because F-Droid contains a minuscule fraction of the apps on the Google Play store and because since F-Droid only allows open source applications it's much easier for them to determine shady behaviour (Google can't simply mandate that all apps on their store be open source).
Of course they cannot. Literally, the Play Store itself and countless other Google apps are not open source. Google doesn't operate on a FOSS model (to the point that AGPL is banned in their company).
I was really looking forward to something like F-Droid on iOS after the DSA came into force, but unfortunately Apple’s absurdly bad compliance has rendered such a thing all but impossible.
Me too! I would've legitimately given iPhone a spin had Apple actually complied with the spirit of the law and not just the fine print.
While F-Droid may be important, I personally tend to prefer Aurora Store and even more Obtainium[1]. Although you have to be even more careful what you install, Obtainium is extremely good at keeping apps up to date.
Some projects don't even provide an F-Droid release, so just adding the github repository to Obtainium is much easier than having to deal with apk stuff.
1: https://github.com/ImranR98/Obtainium
The Aurora Store app is just a frontend for the play store. It's a useful tool, but gives none of the benefits the existence of F-Droid provides to the world. Obtainium just fetches an .apk from a site, also useful, but provides none of the security aspects of F-Droid or the Play Store.
There is no good alternative to F-Droid. Thankfully that's just because it is such a great concept.
hey HEY! fdroid all the way! I do the web sight sign in every time! java cookies dom get switched on selectivly de google till it breaks and then factory reset and try again linux laptop and adb keeps my pics and files, move them to a thumb drive once in a while I almost never see any adds and can do all the "things" just fine but like the article says,you gota be brave
less coffee more nix
perceptive looking into nix
I use android and my first place to look for apps is fdroid. It doesn't have the best search and it doesn't have many apps. But I have hit the jackpot on a few apps and that's more than enough to justify its existence for me.
It's particularly good for very niche use cases, like, you might need an app that simulates dice rolls, then fdroid might be the best place for that as you'll find an app that does just that and nothing else. No ads, no bullshit.
If fdroid doesn't work for me then I will give in and search for "commercial" (ads or paid) solutions.
In some security circles, use of F-Droid is discouraged:
https://privsec.dev/posts/android/f-droid-security-issues/
https://www.privacyguides.org/en/android/obtaining-apps/#f-d...
My understanding is that this largely stems from the fact that F-Droid compiles and signs all the apps on behalf of the application developers, so there is a loss of control there. Some will say that this is what redistributable builds are for, but in my experience they are not actively/widely verified even if they do support it, especially publicly.
Privacyguides isn't very good in my experience. It's got a real "blind leading the blind" thing going on, where a bunch of half-truths are repeated ad-nauseam because at some point, someone told them that thing X is bad for your privacy. It's probably best exemplified in how they can't seem to stop recommending Brave, even though you're probably better off just loading up literally any other browser that isn't Google Chrome with privacy extensions instead.
Practically speaking, you should just assess the following threat model; which is going to be a greater threat to you:
* An application developer who can be bought out and have their tools replaced with adware. (Ref. https://news.ycombinator.com/item?id=38505229 )
* The F-Droid servers, where the most realistic threat is a rogue actor obtaining the keys.
That second one is also mitigated by the fact that F-Droid generally prefers to practice "reproducible signing"; basically they'll distribute the developers apk, not the one on F-Droids buildserver, if the F-Droid release matches the GitHub release (minus the signature obviously), making the signature problem mostly a non-issue.
For most people, I'd argue the former (a "surprise update" to insert anti-features[0]) is a greater risk than the latter, so F-Droids model fits them better. The sole exception would be extremely privacy sensitive apps where trusting the developer is more paramount than having the second man in-the-middle that F-Droids maintainers are. (A basic example of that would probably be Signal.)
[0]: As defined here, although not all are relevant for users: https://f-droid.org/docs/Anti-Features/ , although I'd just add de facto adding pointless microtransactions and subscriptions to this list. They're just not included since F-Droid wouldn't ship them.
This is part of the longstanding devs vs. distros tug of war. There is a loss of control for the devs, but it's better for the user to have distros like F-Droid. The alleged security benefits feel paternalistic, like the dev knows best so only they should be able to sign binaries. Why someone would get into FOSS development and then get upset when someone exercises their rights to build from source and distribute binaries is baffling to me.
> Why someone would get into FOSS development and then get upset when someone exercises their rights to build from source and distribute binaries is baffling to me.
This happens at an alarming rate within the video game emulation community. Many projects (including MAME) have openly expressed deep disdain for any forks existing at all. It's like they think any difference a fork has is a negative thing and then aggressively attack that... as if there is only one way to write software. Some projects have even stopped upstream development entirely, or closed the source or changed their license... just over forks. License violations (including GPL as well as non-commercial ones) are also rampant there.
> F-Droid compiles and signs all the apps on behalf of the application developers
At least they are open and honest about it. As opposite to Google, who promised to let developers do the signing, but soon (after gaining worldwide popularity) took over with extremely shoddy justification.
Isn't this the same situation as with linux software repos?
Yes and it is often a source of contention as well, not only for those same reasons but also others. For example, package maintainers often configure the programs differently (see: keepassxc drama) and often the users expect support from the upstream for problems they have no control over, sometimes even causing the upstream to stop development entirely due to the entitlement and abuse of downstream users.
Do these same concerns still pertain to dev-hosted F-Droid repos? (E.g. I am thinking of how I install Bitwarden from the their own repo: https://mobileapp.bitwarden.com/fdroid/)
IMHO, one of the best parts about the F-Droid ecosystem is its openness. Security models are not a one-size-fits-all and it is important to me to have access to software from multiple sources.
Dev-hosted repos are the same as downloading from the developer's site, they offer none of F-Droid's guarantees
The first source you linked is run by GrapheneOS community members so it's slightly biased: https://privsec.dev/about/
Why would GrapheneOS be biased against F-Droid? It's not like they have their own app store. (They have "Apps" but that's not any competition.)
I'd bet good money that Madaidan was Daniel Micay
Packager middlemen give me a layer of protection against application developers selling out to malware companies.
F-Droid already saved me from this: https://liliputing.com/android-app-maker-simple-mobile-tools...
I trust F-Droid more than $RANDOM_GITHUB_ACCOUNT.
I say that possibility is canceled out because those layers of protection also provide avenues for additional bad actors and even more possibility of places to inject malware/compromises.
They might provide additional avenues, but they remove others, so it's hard to assess what's safer (I'd lean towards F-Droid-like solutions).
The best of both worlds is where both the developer and a third party certify the builds, as happens with F-Droid's reproducible builds.
On Android you're still left on deciding whose signature to put on the binary, however (I'd prefer one from the third party, differently from what happens with F-Droid reproducible builds).
It would be nice if both parties could sign the binary. My biggest issue with reproducible builds is that not every project supports it, and many that do aren't being verified (like Signal).
Examples of that? Debian has about three decades of history, have any of their packagers ever sold out?
I was more referring to supply chain attacks and intentional backdoors, which have happened multiple times in the past. Debian servers have also been hacked before.
Security is a while different topic. The article is about the positive aspects of demopolisation, freedom and competition.
Except for some apps for financial institutions, all my apps come from F-Droid. I feel like I can trust their vetting but absolutely cannot trust random apps from Google's store. Why is it that unpaid volunteers can do better than one of the largest tech corps on the planet? Google is pathetic.
There's no overwhelming financial incentive in open-source applications, while both mobile stores are a constant arms race in monetization, advertisement and shady practices, where legitimate and privacy respecting alternatives are relegated to obscurity and difficult to find even if you're specifically looking for them by name. In some ways FOSS software is even discouraged from being published due to some rules (see for example donation links being strictly forbidden) and the probability of fake malicious apps, like NewPipe or SimpleMobileTools clones.
Because F-Droid contains a minuscule fraction of the apps on the Google Play store and because since F-Droid only allows open source applications it's much easier for them to determine shady behaviour (Google can't simply mandate that all apps on their store be open source).
Google could do that!
Of course they cannot. Literally, the Play Store itself and countless other Google apps are not open source. Google doesn't operate on a FOSS model (to the point that AGPL is banned in their company).