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.
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.