F-Droid: how it weakens Android's security model
wonderfall.dev
wonderfall.dev
This is fallacious for several reason.
Firstly, no I do not "have to trust the developer anyway" - I can always not install the app. I'm not starting with an app, adding my trust of the developer, and adding my trust of F-Droid - I am starting with F-Droid, and only installing apps which F-Droid trusts, because F-Droid's criteria for accepting apps are far more stringent than Google Play's - more stringent even than I could feasibly audit myself.
Secondly, trust is not binary. Maybe I trust the developer enough to run their published source code, but not quite enough to run their precompiled binary that they might have slipped some tracking library into. Indeed this is very common and F-Droid strips a lot of such libraries. So even if we take it as a given that I am definitely going to install an app, and my only choice is between installing it from Google Play or from F-Droid, F-Droid is still superior because the builds on F-Droid are built from public source, and I am much more sure that F-Droid themselves won't slip malware into the builds because they have a track record of not doing that.
Thirdly, Android's default app store, Google Play, also trusts a third party by default - Google, who insist on running a tracking rootkit on your computer, which is so much more egregiously invasive than trusting any one app that it renders any comparison with F-Droid moot.
[0] https://developer.android.com/guide/app-bundle
[1] https://developer.android.com/guide/app-bundle/faq#app-signi...
It's a shame these platforms go to such great lengths to force distribution through their "safe" channels.
Yeah that doesn't help with coercion or government letters, but neither would being a solo dev, both parties will comply.
A team-maintained package repository on the other hand operates through transparency.
> I'm not starting with an app, adding my trust of the developer, and adding my trust of F-Droid
You are. You seem to believe they actually read the whole source code when it's not the case: all they do is running their own scripts to scrap known trackers and the like (and again, I must say badness enumeration is a flawed approach), this is far from a stringent process and this would be a very weak approach in any threat model to rely on that.
You still have to trust the app developer, and you'd be much better off trusting the strong guarantees provided by the Android app sandbox anyway. Seems like there's a major disagreement here when it comes to our approach to privacy.
> Thirdly, Android's default app store, Google Play, also trusts a third party by default - Google, who insist on running a tracking rootkit on your computer, which is so much more egregiously invasive than trusting any one app that it renders any comparison with F-Droid moot.
Play App Signing is mentioned in the article.
Which Google Play does not, happily serving you all the "known trackers". F-Droid is strictly superior on this front.
> You still have to trust the app developer
I don't have to trust the developer as much because I don't have to take their word for it that the compiled app matches the public source.
> and you'd be much better off trusting the strong guarantees provided by the Android app sandbox anyway
False dichotomy. I still have the sandbox with F-Droid. This is chaff.
> Play App Signing is mentioned in the article.
...Okay? What a non-sequitur. Signing is completely off-topic to the fact that Play Services is spyware (notwithstanding your assertion that it isn't). Unlike F-Droid. That's a huge difference.
It's like saying "when meeting a sketchy stranger, don't bring a friend along or meet in a public place because now you have to trust the friend as well, and also the friend might not be strong enough to overpower the stranger anyway. Safer to take an Uber to their house and lock the door behind you."
I didn't imply that you wouldn't benefit from the app sandbox by using F-Droid. I meant that the practical approach to privacy should come from relying on the permission model instead of trusting third parties.
In that sense, F-Droid adds very little to the fact that you still have to trust the upstream code with the permissions you're willing to grant.
If you choose to trust F-Droid, that's perfectly fine and I'm not trying to convince anyone to stop doing that. I also won't comment on your statements that Play Store is spyware because I have very little interest in that topic. You're free to believe that, and I respectfully disagree given the great service (whilst not perfect by any means) offered by Play Store.
Looking a little closer, AFAICT, they have only filed 2 GrapheneOS PRs ever: https://github.com/GrapheneOS/platform_packages_apps_Setting... and https://github.com/GrapheneOS/platform_packages_apps_SetupWi...
I have been using for the past year, and the 'advanced' user experience is not great. Updates are forced to the latest version of android, does not seem safe, and definitely does not feel stable, less customization than other roms, a bit aggressive towards root
I will probably go back to lineageos microg f-droid and some hardened configurations
F-Droid is provides invaluable service for android, privacy, open-source, android developers. GrapheneOS seems like an exercise in craziness a bit to extreme for me
They are making an alternative store with better security and privacy properties than both Google Play and F-Droid. Why is this problematic?
> Updates are forced to the latest version of Android
On Pixels (the only devices GrapheneOS supports at the moment), only the latest version of Android receives security updates, so GrapheneOS must stay on the latest version to meet a baseline level of security. Each Android release also comes with security and privacy improvements along with further restrictions to the app sandbox.
> does not seem safe
How is GrapheneOS not safe?
> does not feel stable?
In what way?
> less customization than other ROMs
Yes, because GrapheneOS is not focused on customizability. This will be improved in Android 12L.
> a bit aggressive towards root
Root fundamentally cripples the Android security model, so being a security-focused project, this is the proper stance to take.
Honestly I'm not sure why you're complaining about GrapheneOS in this thread. The article is written about F-Droid by someone who is not a GrapheneOS developer. They pointed out F-Droid's issues and mentioned upcoming alternatives without these issues. I don't see how one of those alternatives is an "exercise in craziness," nor how GrapheneOS itself is relevant to the article.
In the GOS chatrooms this article has come up a few times but I've seen them say they don't know why people keep saying this person is a GOS dev. I mean look at the author's github. They sponsor the lead dev but have no commits or forks in the project to show for.
I'm perfectly aware of the FOSS culture and why some want to use F-Droid to promote this. This is just not what I had in mind when writing the article. I simply intended to address some flaws or deliberate choices from F-Droid that I think are in opposition to the practical approach to modern privacy/security. It happens that I think GrapheneOS and modern Android in general follow that approach. Last month, a reddit troll tried to portrait me as a GrapheneOS developer (when I'm an occasional contributor) and used the article to explain how GrapheneOS would be "anti-FOSS". That is so wrong. GrapheneOS is FOSS at its core, and I personally value FOSS solutions. Not sure how someone would extrapolate the opposite from my article.
Knowing that, I then stumbled upon this thread and noticed people digging up random contributions in my GitHub account instead of reacting to the content. Contributing to an alternative project doesn't mean bias or endorsement. Contributing doesn't necessarily mean code, GitHub issues, or money. You could even see this article as a contribution to F-Droid in some ways (but I'm sure they're aware of the majority of the underlined issues, and I don't have the pretention to do better than them). Then again, I deeply think GrapheneOS and Accrescent are paving the way for modern FOSS solutions.
2) One person's overly broad API permissions are another person's gateway to programming an awesomely powerful application. Having my storage API taken away for an entire Android release because "hurr durr, security, we'll fix it in the next sprint" and not being able to use a file manager other than the meager thing I had included with my OS showed me how true that is.
But that doesn't weaken the security model — since August2021, (new) Android devs can't sign their own apps anymore, Google holds the keys instead.
The security model already assumes a third party is signing the apps.
A lot of bragging takes place about Play, but is silent on Amazon's appstore or any of the Chinese alternatives.
Yeah well Google fucked up and removed a lot of important API stuff that supported tools.
So I'll continue to use termux from F-Droid. Otherwise I might as well not have a phone.
Not that I'd recommend it personally, but f-droid isn't the only option. Kind of the beauty of open source :). So often apps (e.g. from the government for corona) are only available if you first agree to the Google TOS and privacy policy. Which, of course, most people already did anyway, but the point here is that you don't need to if there's just a build from the devs somewhere, or a build environment you can replicate without too much trouble.
These should be permissions, not disabled wholesale.
Or when you want to store and load ROMs from a folder.
Or in general every time you want to automatically load files that should also be accessible to other apps.
Whole access to the shared storage is deprecated by SAF and scoped storage. That doesn't mean there is no way to achieve the same productivity tasks you could achieve before: it's just that now you're granting explicit fine-grained access to the files and folders your app needs.
MANAGE_EXTERNAL_STORAGE still exists and is now reserved for apps that can justify their file management purpose. Since this is a highly privacy-invasive permission, Play Store requires a review for these kinds of apps.
This is a similar situation to iOS which has a saner app ecosystem for this reason (in my opinion). That doesn't prevent apps with the same purpose to exist. iSH and a-Shell are examples of that on iOS. UserLAnd on Android takes the proot approach: https://userland.tech/
* https://articles.59.ca/doku.php?id=pgpfan:tpp
The article also claims that Debian has moved away from GPG signatures. This is not true.
This all seems like a pointless distraction from the point that article is attempting to make...
I might rephrase that since they didn't technically moved away from OpenGPG (yet). It was a proposal at the time.
Why is that? I've been using the anonymous accounts because I figured sharing an account gives a lot less info to google, and we're downloading the apks directly from Google servers in the end. Is there something I should know?
The point is that F-Droid weakens Android's security model, in other words, F-Droid requires more trust on your part. I think it is reasonable to trust the somewhat niche open source community more than the most popular and therefore the most attacked app store. You may also not want to feed Google, but it doesn't change the fact that F-Droid is technically less secure. The article's debatable suggestion is to get your favorite open source apps you trust from the Play Store to get the best of both worlds.
The article is interesting because most of the points are actually fixable by F-Droid. So it is good to see from a "how to improve F-Droid" angle than "F-Droid sucks".
The article is completely baffling in not really covering that. "strong security and privacy guarantees" mean jack shit when the game from the play store starts leaking all data it can grab or adds bank phishing - and it will have a bunch of permissions anyway, it legitimately needs them to function.
I started to Tweet about a week ago. Most of my tweets get no traction, but if I speak about Ukraine suddenly I get a lot of views. To me it's the proof that Tweeter is controlling what we're thinking about.
It's quite possible the Twitter algorithms are being nasty (i'm personally strongly against AI deciding what to show and how to order it in a timeline), but it's definitely not the only factor at play.
Perhaps that's because I've got half a foot in the foss community and you don't hear a lot of "fml why is f-droid so strict about not using secret code", but to me it seems much more often that people complain about Google's policies than about F-Droid's. Especially since F-Droid's
> “quality control” offers close to no guarantees
because there are no restrictions on things that just work with root, donation links for open source open geo data contribution platforms[1], roll your own payment scheme without giving anyone a cut, put ads in it if you like...
... and yet I have no qualms letting my grandma browse around f-droid but am terrified of what bank phish she might be shown in an ad after roaming the google store. Technically the author is correct here, of course, but in practice this turns out to be a total non-issue. The rules are also not set in stone if it were to become one suddenly.
--- (edited to add)
> Their client also lacks TLS certificate pinning
As does every web browser, but somehow banking on websites seems to very rarely be intercepted? I don't get the fuss about this and I work in the security industry. We recommend the most secure solutions, but sometimes there are trade-offs here:
- Historically it has been recommended to turn off autocomplete in browsers <input> fields. I think we all agree on that one.
- Historically it has been recommended to turn off backups in Android because, gee, someone could make a backup of your app data and what if that's an attacker somehow! An auth token might get out! Nobody cares that this makes it physically impossible to backup your data at all anymore on Android (Apple is doing very well on that front, I am very much impressed there even if it's not enough to make me buy into Apple by a long shot). This is one of the reasons I root my device and make fairly extensive use of it.
- These days it's being recommended to use cert pinning which is a huge pain in the arms for anyone wanting to toy around with what the app does. Now in this case it's open source anyway, but think of, uh, yeah how about what the article mentions: "unlike Play Store which does that for all connections to Google". Wouldn't it be nice if you could actually see what this app sends to Google about you? Previously you'd add a cert to your OS and you'd be good to go. Now you have to modify the compiled application: a steep learning curve for anyone not working with app pentesting on a regular basis. For a high-security app like your banking app, alright, but for most other things I (as a tech nerd, clearly, I'm not an average user) think it's more harmful than beneficial.
> their website has (for some reason) always been hosting an outdated APK of F-Droid, and this is still the case today
Part of this sentence is a link to the forum. If you actually click that link, the "for some reason" becomes perfectly clear: f-droid-the-apk releases are shipped whenever it is ready, there is no beta channel in that sense. Whatever is on the homepage should work for everyone with any setup, and from there you can try to upgrade. If that fails, no biggie, you can just use the older version that works. Is what the forum says. (Not that I ever had a broken f-droid version myself, so not sure how important this really is.)
> F-Droid is not the only way to get and support open-source apps. [...] Most of the time, releases are available on GitHub, which is great since each GitHub releases page has an Atom feed.
Hah, the author just spent ~2800 words criticizing the liberal inclusion policy, missing api target enforcement, outdated (now slightly misleading) permission listings, lagging signature scheme update, and then concludes with "just download the apk from github because it has an Atom feed"! If only f-droid knew that this was the requirement for an endorsement by OP :D (jk)
No really, use f-droid instead of github please or make sure you know how to check pgp signatures and have a chain of trust to the developer somehow. Or trust microsoft/github blindly, that's okay too (many of your apps come from there indirectly anyhow, if I'm being fair). But as blanket advice for a source of apps? That's... interesting in this context.
> > Should I really care?
> If security (and privacy, as they overlap) matters to you [then yes]
It depends.... how much does security matter to you? Is this to the exclusion of all other values?
It's a bit black-and-white. But then, yeah, as others said, the author works on their own security-oriented Android flavor (which is very good work by the way!).
[1] see "un-features" https://github.com/streetcomplete/StreetComplete/releases/ta...
Edit: was this marked as off-topic or why is it stuck to the bottom despite upvotes? Usually neutral comments float somewhere around 2/3rds of the page, this comment is not neutral but upvoted and is at rock bottom.
Not to mention that an app may be hosted on a different platform, perhaps one that doesn't do auto-builds. Or, as was already pointed out, builds do exist but contain telemetry or secret code. In that case, a trusted intermediary (which I trust heck of a lot more than Google) that pulls and compiles the code and then distributes it, is a strictly value-added proposition.
For what you're asking for, IzzyDroid's repo may be the closest to what you're asking for.
F-Droid can't do anything against "secret code" since they don't/can't analyze the whole codebase. Like said multiple times, they only run a few scripts on the available source code to remove known trackers, which is known to be a poor approach to privacy.
That said, I should really set her up with a third party repository for updates.
Respectfully, that was not my point. The point was that having access to the source code fundamentally doesn't mean much. You can read more about why there since I don't want to open this debate again: https://seirdy.one/2022/02/02/floss-security.html
> As does every web browser, but somehow banking on websites seems to very rarely be intercepted?
Banking apps exist, and are required as a modern 2FA. Since 2021, strong 2FA is a requirement in the EU for banking operations. Mail clients also do this. DANE would be the ideal approach on web browsers. This might be up to a more general debate that doesn't belong here though.
> Wouldn't it be nice if you could actually see what this app sends to Google about you?
It's perfectly nice, and mitming is a great tool to ensure Google (and others) doesn't lie about what data they send.
> Previously you'd add a cert to your OS and you'd be good to go.
Now, this argument is rather moot though, since it's still doable. Not sure that the higher technical barrier would matter much, and most users will benefit from having certificate pinning anyway. Google is not doing this to prevent researchers to do their work. Nothing is permanently a blackbox anyhow.
> Hah, the author just spent ~2800 words criticizing the liberal inclusion policy, missing api target enforcement, outdated (now slightly misleading) permission listings, lagging signature scheme update, and then concludes with "just download the apk from github because it has an Atom feed"! If only f-droid knew that this was the requirement for an endorsement by OP :D (jk)
This is a bit exaggerated. I'm merely stating this is an alternative for "tech nerds", since Android enforces signature verification for app updates, so you once you ensured the authenticity, the source doesn't matter as much. This should be done with apksigner by the way, not tools like OpenGPG.
I didn't feel the need to expand on this.
> It depends.... how much does security matter to you? Is this to the exclusion of all other values?
I rephrased this conclusion, since it was indeed a bit binary for my taste.
This article wasn't meant to be openly shared on public platforms. This was bound to happen, but obviously I was not trying to make an article that should reach everyone. This is fine though, thanks for your comment.
Update: I think you must have been caught in some automatic system because every comment (including your account's first) was already marked [dead] but not [flagged]. This does not seem to have been users flagging you or anything, maybe you use an IP previously used by a troll or so? Or a keyword detector in the first comment set it off (e.g. since the words "You're wrong," might trigger he-said, she-said conversation when taken by itself) maybe? Idk. /update.
> This is a bit exaggerated.
Yes, I was mostly joking in that cited part, that's why I added "(jk)" :). I understand there's much more to it than just that, it just read funnily to me. (Not meant as laughing 'at' you! Hope it didn't come across like that.)
> once you ensured the authenticity, the source doesn't matter as much.
Yes, but that's TOFU. Secure in most cases, but if it's used all the time, an attacker will catch today's lucky ten thousand (xkcd.com/1053) who first download a certain app or who just (re)installed their phone.
Hence my suggestion of something like PGP, where the authenticity can be established more reliably than having everyone hope it wasn't compromised on first download. (It's a good alarm mechanism though, if suddenly everyone else's update fails, so any compromise of app signing keys wouldn't be long-lived. But I do feel like the article argues for a much higher security standard than TOFU.)
Alternatively with f-droid, the CA system is used, and TOFU doesn't go away. If the CA system is compromised, there are still the app signing keys. Conversely, if the signing keys are compromised, the attacker also still needs to compromise the distribution channel or server.
(Also I would like to correct myself on my previous comment: I meant "GPG" as the reference implementation of the OpenPGP standard, not "OpenGPG". I was very tired.)
> I understand there's much more to it than just that, it just read funnily to me. (Not meant as laughing 'at' you! Hope it didn't come across like that.)
No worries, irony doesn't hurt.
> Yes, but that's TOFU. Secure in most cases, but if it's used all the time, an attacker will catch today's lucky ten thousand (xkcd.com/1053) who first download a certain app or who just (re)installed their phone.
By authenticity I meant that you can already use apksigner to verify the fingerprint of the signature. For instance, Signal publishes the fingerprint on their website: https://signal.org/android/apk/
Since the APK published on the website is the same as the one published on Play Store, I think this can be a nice way to ensure the package hasn't been tampered with. A properly configured HTTPS server should be the baseline, with CAA and CT to ensure it wouldn't be easy for an attacker to issue rogue certificates for the website. Of course, this is still involving a TOFU model like you said with any CA system in the end.
Therefore, having certificate pinning by default for the app repository should be a nice progress to deter several types of MITM attacks (rather than placing too much trust in the distribution infrastructure). This comes nicely along the app signature system which inherently follows the TOFU model on Android.
Alternatively, GrapheneOS (as a hardened OS) has the idea to ship a database of known-good signature fingerprints for top used apps such as Signal or Element. This would be hard to do for apps that also have a third-party F-Droid build due to them reusing the package IDs in most cases (the OS can also whitelist the signatures for those, but this isn't ideal).
Ah, fair point, there indeed my logic does not apply. On GitHub releases with apk downloads, I've never seen a fingerprint and including it on the GH platform itself would not help either, but indeed nothing prevents the maker from using some other place to publish key material.