I hadn't read that and it's informative. Let's paraphrase and dissect its arguments.
> 1. F-Droid releases are signed with F-Droid keys, and Google Play releases are signed with Google Play and app developer keys both
I don't feel this is an issue. Google is the party in exclusive control of which app developer keys are deemed valid, so the app developer signature adds exactly nothing. You either trust the channel to give you a correct application or you don't, and I think it's quite silly to implicitly suggest that end users would verify app signatures to notice a compromise of the app store they use.
> from June to November of 2022, [F-Droid's] guest VM image officially ran an end-of-life release of Debian LTS
This is in the past and not a strong argument. We don't know what individual app devs run on their build boxes - some of them are surely the devs' own laptops infected with malware, so this argument cuts more strongly against Google than for it.
> While deterministic builds are a neat idea in theory, it requires the developer to make their toolchain match with what F-Droid provides
This is straight-up dismissive bullshit. Reproducible builds are a valid alternative to signing the build output, and in my opinion superior as they guarantee you can actually build the app from its sources.
The paragraph containing the explanation of why deterministic builds are a bad idea is the type of paragraph I was railing again when I wrote my previous comment: it undermines my faith in the Graphene devs' judgement.
> 2. F-Droid app releases are slower and less frequent than Google Play releases
Some apps update on F-Droid faster. This is mostly down to the app devs and the relative popularity of the two stores. The Graphene devs try to make the argument that there's something in the F-Droid build process that's not automatic, but so far as I know this is not true.
Also, again, my point of view is that "faster updates" does not mean "more secure". If you quickly release a new vulnerability that's bad, so I'd rather have strong review of each new software version.
> the fact that their build process is often broken using outdated tools
Users should be free, when informed, to do this. It's not a security problem. F-Droid displays the target SDK level. I don't think we should automatically consign all unmaintained software - and devices - to the graveyard in the name of security.
> 4. We generally don't like the dev practices of the F-Droid maintainers
Outdated information here again, talking about things F-Droid doesn't do any more like using jarsigner. If they wanted to say "we don't trust F-Droid to do the right thing" just say that and delete the rest of the page, but it's an opinion not some kind of factual stance.
Or, you know, pick the particular problems you have with their practices, and then start supporting them instead of tearing them down when those problems are fixed. As they are now.
> Their client also lacks TLS certificate pinning
The client downloads apps and verifies their signature. This is the first argument I've seen here as legitimate, because although the problem is minor, connecting to the "wrong" store means you see the "wrong" versions of apps. But of course you couldn't use this to inject malicious code, because again, verified signatures. The devs on the page just say it could "lead to various security issues" which is overly vague for me to address more directly.
> 5. The F-Droid client has a confusing UX
Not a security issue.
> 6. The F-Droid client has a confusing UX specifically about permissions
Not a security issue.
> Play Store restricts the use of highly invasive permissions such as MANAGE_EXTERNAL_STORAGE which allows apps to opt out of scoped storage if they can’t work with more privacy friendly approaches
I should have the ability to install applications that work how I want them to work. Google shouldn't be able to prevent me from having a Gamecube emulator that stores its save files on my MicroSD card in a performant fashion.
My overall verdict is that the page you linked (thanks) confirms my opinion of the GrapheneOS' developers stance: they choose a position, and then they throw together whatever arguments they can find that might be construed to support that position, regardless of merit. They intentionally use vague wording when they know the position they're supporting is weak, to instill fear in less-tech-savvy users who cannot sort the bullshit from the substance. It leaves me with the feeling they're not arguing in good faith.
Can't say anything for the impression you get from the style but I can at least say that GrapheneOS argues different things and differently on quite a few of the points made about F-Droid. They have also always been big advocates for open- source Android apps and explored/implemented F-Droid integration in their OS at points in the past.
I'm familiar with the PrivSec people and they are different from GrapheneOS with a tiny bit of community/mod overlap. There isn't any GrapheneOS dev presence in the PrivSec project.
https://privsec.dev/posts/android/f-droid-security-issues/