I tried GrapheneOS recently and switched back just because I lost my automatic backups. The backup solution and syncing should have been solved before some of the other design choices IMO. I was also disappointed to see that there is no way to prevent the warning message on each boot, which seems to delay the startup (or at least none that I could find).

Other than that, I could be content with it.. it may not be perfect, but it felt good to know that I wasn't tied into the Google eco system. I liked their contacts and location sandboxing.

I've heard some complaints about GrapheneOS's choices and wish that there was more communication from the lead developers about their design choices, just to understand them a bit better. However, I do think some users are just reactionary overall to some things. They hear Chromium and just assume it is worse, but honestly have no clue from a development perspective. All your complaints sound legit though and I too would like to know the answers, because you bring up very valid points.

There has been some drama in the F-Droid community, and I too tried alternatives, but in the end... my favorite apps all recommend F-Droid, and I find using F-Droid 10x easier than the alternative of managing apps from random locations. I believe the biggest complaint with F-Droid is that it is a single-point of failure or compromise since they sign the packages and updates can get delayed, however, in reality adding random Git repos to Obtanium or whatever is just as insecure. I believe Fdroid even does some security scanning too, but I could be wrong... which is an added bonus.

Most of the GrapheneOS information you might be interested in is in a few different places (Reddit, Twitter, Discord) but quite predictably they have become unworkable for searching especially if you don't have an account on those platforms. GrapheneOS also has their forum for that purpose but it is quite young compared to the project.

>I was also disappointed to see that there is no way to prevent the warning message on each boot

That bit is part of Android https://android.googlesource.com/platform/external/avb/+/mas... and would be the same on any device following the same implementation model (most of the Android world although some don't do it properly). They have been looking into a hardware company partnership though, which could potentially mean a device that boots GrapheneOS without such a warning.

>All your complaints sound legit though and I too would like to know the answers, because you bring up very valid points.

Some of the points raised might be argued by community members but that does not mean they are representative of the GrapheneOS project's positions. I would stick to the official GrapheneOS accounts on social media if you want the project opinion. The founder is also a fully public development member of the team so you can look to their posts for official positions as well.

>in reality adding random Git repos to Obtanium or whatever is just as insecure.

Yep, I believe this also isn't officially recommended by GrapheneOS either anyway. GrapheneOS had always been clear that one of the big benefits to basing on AOSP is the massive ecosystem of open source Android apps. They also integrated F-Droid and collaborated with the project in the past. Their requirements for app stores have developed in line with their project goals over the years so there is a lot they are looking for now in an app repo that F-Droid does not provide.

> MicroG is "insecure" because it requires "signature spoofing

But it is literally a less secure option, than what Graphene does provide, sandboxing the original google api itself.

> pixel

Yes, if you can literally just start any OS from the hardware level, you don’t have security. The same way you can just read/edit an unencrypted linux distro partition, and “login” to that same OS.

> But it is literally a less secure option, than what Graphene does provide, sandboxing the original google api itself.

Let's define "less secure" as "vulnerable to additional threat vectors when compared to another option".

If the operating system allows a verifiably signed MicroG in /system to replace Play Services, what is the threat vector that opens up? Keep in mind that I'm intentionally trusting MicroG more than Google, so anything that happens as a result of a compromise of MicroG itself is a trade-off for avoiding anything that happens as a result of a compromise of Google Play Services and so not "less secure".

Explain what "less secure" means in this context, please, because I don't get it and nobody ever have.

> Yes, if you can literally just start any OS from the hardware level, you don’t have security.

That's not how Samsung Knox works. It's verified boot.

Also, I don't care if any OS can start if any OS can't decrypt the encrypted root partition due to it using a TPM-held key backed by measured boot registers, and that's also possible on several phones.

MicroG means that there is a mechanism to spoof app signatures, which is a core security measure.

As I said twice, LineageOS allows the exact signature of MicroG to replace the exact signature of GMS (core google play services component).

An app signed as MicroG can't spoof anything other than GMS. Nothing with any other signature can spoof GMS. An app not signed as MicroG cannot spoof anything.

I'm unclear what the problem is here, because the desired outcome is MicroG replacing GMS and that is exactly what LineageOS allows, without allowing anything else.

> F-Droid is "insecure" (I can't address this one because I don't understand the point of view and I've never seen it clarified)

https://privsec.dev/posts/android/f-droid-security-issues/

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

This is bullshit sand-kicking, again.

> 3. F-Droid allows users to install apps targeting lower Android SDK levels

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.

> My overall verdict is that the page you linked (thanks) confirms my opinion of the GrapheneOS' developers stance

I don’t think this page is affiliated with GrapheneOS. See https://privsec.dev/about/

I think it's a sock puppet, because the stylometry on the page is a perfect match for the "GrapheneOS" account on discuss.grapheneos.org .

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.

I hate Pixel exclusivity and dropping past-EOL phones, but Storage Scopes (aka unveil()) is the biggest reason I stay vs switching to an alternate.

>The one that really grates on me is the last one: I don't want an OS that chooses an app developer's "don't copy this file" flag over my desire to copy it!

Wholly agree. I think we have a huge problem with loss of [device] owner-sovereignty in the economy, with enshittification, rentiering, and surveillance capitalism rising to sap away more value from customers like customers are some sort of planter garden to glean from.

Business today has become like the drug dealer business: how do we get 'em hooked and coming back for more and more? Selling a lasting quality product at a painful but fair premium is out, sucking wallets dry $1.49 at a time for somethings which last a short time before "engineered obscelescence" kicks in to force a re-buy is the in game now.