>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
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.
I fail to see how it's fallacious since you're confirming my point.
> 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.
>all they do is running their own scripts to scrap known trackers and the like
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."
> False dichotomy. I still have the sandbox with F-Droid. This is chaff.
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.
The "tracker checking" is useless because it just checks for a small list of libraries in the app. If an app has no tracker libraries, this doesn't mean that they do not track you. So it gives you a false sense of security.
Yes, last I checked, Google signs the app with your private key, which they force you to give them. In other words, they have the ability to make any changes to your app and re-sign it at their whim. Anyone concerned about the security of their shit should only install apps directly signed directly by the developer, using a private key only the developer possesses.
It's a shame these platforms go to such great lengths to force distribution through their "safe" channels.
Playing devil's advocate, given the choice between trusting a random developer to keep their keys private or Google to keep their keys private, I'd probably side with Google.
Yeah that doesn't help with coercion or government letters, but neither would being a solo dev, both parties will comply.
Except the developers can still have access to the key, they just have to share it with Google. This not only violates the old advice: "Never share your private key!", it also gives you the worst of both worlds: You have to trust both the random developer and Google to keep the keys private.
I don't think the concern is with Google keeping the keys secure. I think the concern is with Google being able to rewrite the app however they want and sign it without the developer even knowing.
What Google does with their keys is known only to Google. Google also have various commercial pressures which can compromise their behaviour (on that note, have we even managed to stop Certificate Authorities selling carte-blanche certificates to middleware-box vendors yet?)
A team-maintained package repository on the other hand operates through transparency.
Not to discredit the article, but it would be nice to know from the get-go that it's written by a contributor to GrapheneOS and gives a plug to their upcoming App Repository at the end.
I'm not saying that the author has never contributed a PR (there'd be a lot of repos for me to look through), but AFAICT the author is just a user/fan of GrapheneOS, not a contributor to GrapheneOS itself or to the GraphenOS App Repository.
After reading the article, I clicked the link to their Github and saw a @GrapheneOS tab in their contribution graph. But taking a second look, I see that they haven't contributed to any of their repos in quite some time.
I was already under the impression that the GrapheneOS developer(s) were overworked, but still they insist in doing everything themselves because no other project is good enough
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 insist in doing everything themselves because no other project is good enough
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.
Author here. I'm neither a GrapheneOS project member or an Accrescent developer. I'm trying to push these solutions because I think they actually do things right. It's really frustrating that the first reaction for some would be to think that my motivation is to push alternative solutions for my own benefit. Let's try to move past this and other irrelevant personal judgments.
As I said, my comment wasn't to discredit the article by revealing a hidden motive. When reading any review, it's simply good to know what the reviewer's biases are. Which I would say contributing to the GrapheneOS repos, letting the GrapheneOS community proofread your article, and mentioning the project's F-Droid alternative is a proof of bias, not that it's necessarily a bad thing, but would have cleared the air if it was shown upfront.
Well, surely there are biases in some ways, including some I may not even be conscious of. That being said, I try to follow a fact-based approach: yes, the conclusion is biased in the sense that it was written in a personal context (again, this article wasn't meant to be shared on several platforms like HN), but I can assure you the rest of the article follows this fact-based approach as much as possible. I even mention build reproducibility and Play App Signing: both mentions could be seen in favor of F-Droid (yet the reality is more nuanced than that).
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.
This person isn't a grapheneOS developer. I'm unsure why people keep saying that.
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.
1) In the FOSS culture, there are higher standards around keeping devices functioning for longer, compared to commercial ecosystems. Enforcing a higher target SDK version improves "security" (whatever threat model that's supposed to protect me against), at the cost of turning more old Android phones into e-waste. Even Android 4 phones are still usable if permanently plugged in (to counteract battery degradation), and their hardware specs are still perfectly capable of functioning as a 720p YouTube machine, an internet radio, or whatever else comes to mind.
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.
Author here. You're wrong, as I spent several paragraphs explaining how Play App Signing works and how it's being enforced for new app bundles. The Huawei app repository has a similar approach to Play Store, and to my knowledge Amazon app repository has always been doing this (and even more nasty stuff: https://developer.amazon.com/docs/app-submission/understandi...).
That's not a sustainable approach as these old APIs will be obsoleted by a future version of Android. The correct approach is to follow modern practices that will guarantee security & privacy. In the case of Termux, they're well aware of the issue:
https://github.com/termux/termux-app/issues/2155
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/
If you trust Microsoft/GitHub more than F-Droid, you could also grab it from there: https://github.com/termux/termux-app#github (you'll have to take care of your own update mechanism though)
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.
Yup. Raising the target SDK means that more phones become ewaste, not because of their hardware becoming outdated, but because their software will never receive an update.
Raising the target SDK just turns a general computing device into a glorified webbrowser, because you lose access to the filesystem, the ability to run background daemons, and the ability to run compilers.
These should be permissions, not disabled wholesale.
Literally the only situation when an app would need access to your filesystem is when the app is a file manager. And file managers can still request access to your file system.
Not at all. If you want to support e.g. playlists you need to be able to load video files while the storage framework only gives you access to the playlist file.
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.
Unsure why you think the storage access framework doesn't let you grant access to a directory. You can literally try it on a relatively modern app such as Lemuroid: the system file picker lets you grant access to your ROMs folder.
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.
Thanks for this article, it makes very good points. In particular, about the UX of GPG, i've found Sequoia to be a very good alternative: https://sequoia-pgp.org/
F-Droid demands more trust but it is also infinitely more trustworthy than the Play store. It looks like things can be improved (a lot) and I hope it does. F-Droid provides an invaluable service to those who value privacy and open source with very few volunteers.
As others have pointed out, this isn't even true anymore. Google's Play Store model lines up with what F-Droid is doing (effectively), so it doesn't really demand more trust, just different trust.
> [in] a third-party Play Store client called Aurora Store [...] I’d recommend against using the shared “anonymous” accounts feature: you should make your own throwaway account with minimal information.
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 anonymous account is picked from a pool of real accounts. The username/passwords are hardcoded into the app I'm pretty sure? So basically the aurora devs can login to this account and see the crap everyone's been downlidng (Id assume?)
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".
But it's irrelevant trust. Stuff about signatures and specific practices. What makes F-Droid more secure are the kind of apps that are in it, that the apps are FOSS alone makes it less likely for spyware to be added to them. Sure it can still happen and then F-Droid's security practices become relevant. But each time you install an app, there is more trust you can give to an app in F-Droid, than the basically zero trust you can give to proprietary app in the play store.
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.
The article is just a list of insecurities of F-Droid. In fact, it even mentions that you can still use F-Droid if it fits your threat model or for ideological reasons.
My adversary is Big tech trying to control what I see, buy, experience, even think.
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.
For sure more people (and bots) are searching for it. It's also quite possible some people following you (or the people who retweet you) are more interested about this hot topic: you could probably write a dozen tweet about monads and not get any interest, then post a single tweet about Julian Assange or Kim Kardashian and suddenly feel like the entire planet is talking to you.
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.
> [devs] have to maintain a slightly different version of their codebase that should comply with F-Droid’s requirements
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!).
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.
The main problem with downloading APKs from the GitHub releases page, is that it doesn't come with a low-friction way of distributing updates. This is especially important for unofficial client apps like NewPipe, which basically become bricked at a moment's notice, and updating within a day or two is important to maintain continuity of service.
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.
That's a very good point! Although, would it not be trivial to setup a 3rd-party F-Droid-compatible repo that just distributes CI/CD artifacts (eg. Github releases) by subscribing to a RSS feed? I personally wouldn't do it for the reasons you mentioned, but it could certainly be useful for some people.
Ah yes, but this requires adding one repo per app. I meant having a "single" (though selfhostable) Fdroid gateway to CI artifacts so i could just add "cidroid.org" repository to my Fdroid then choose for each application if i want it from F-droid repo or from fresher CIDroid.
Thanks i was not aware of this! It's almost exactly what i was looking for, although admittedly i wanted something more automated (along the lines of here's an RSS feed of releases, use this xpath query to extract the download URLs for various architectures).
Funny you should mention NewPipe since they discourage users from relying on the official F-Droid repo for the very reason of slow updates, which you don't want for an app relying on parsing web pages that are likely to change. The app itself (at least the regular build provided by the developers) sends you a notification once a new update is available. They also maintain a third-party repository, which again is fine at mitigating some issues of the official repository (while breaking the security model because the OS inherently wants one source per app repository, but at least it's more usable than waiting for the F-Droid build to be updated).
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.
I actually use direct APK downloads for myself, and F-Droid for my mother, who is far less technical and therefore benefits from the easier end-to-end UX for the update process. Even with delayed updates, having NewPipe unavailable for two or three days is preferable to using the official YouTube app in the Play Store, which doesn't have the features she relies on at all, or a direct APK download that may expose her to the risk of malware.
That said, I should really set her up with a third party repository for updates.
> 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...
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.
FYI your comment was marked [dead], I vouched for it because I think it contributes to the conversation.
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.
Thanks for the heads-up! It's also a new account since I've never posted on HN before, so maybe that's why.
(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.
Just an offtopic procedural note (I'm a mod here) - some of your comments were indeed getting caught in software filters, plus you were being rate limited (these are restrictions on new accounts because of past abuses by spammers and trolls). I've marked your account legit now so those things shouldn't happen again.
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.