While I share the concerns about Android, it feels silly to me to go back to Linux's (nonexistent) security model and bad mobile UI/UX. Why not try to fork AOSP or GOS (for broader device compatibility, even if it means giving up some its sexy security properties)?
Note that this could include packaging Linux GUI applications as Android APKs (with some additional glue code and Wayland/DBus integration of course), so it's not even an either or.
GrapheneOS are against using their development resources on a platform that is drastically, significantly worse than the hardware platform they already have, which is quite fair. It is not about Pine64 or Purism's products specifically. They would not be against them if they met 95% of the requirements detailed in https://grapheneos.org/faq#future-devices. It would more sense to explain which of those requirements you think are unreasonable.
Uhh no? One of the biggest differences probably is that Android applications are heavily sandboxed:
> Applications are security principals. The main difference to traditional operating systems that run apps in the context of the logged-in user account is that Android apps are not considered to be fully authorized agents for user actions. In the traditional model typically implemented by server and desktop OS, there is often no need to even exploit the security boundary, because running malicious code with the full permissions of the main user is sufficient for abuse.
I just confirmed that Android uses a largely unmodified kernel, so in theory it should be possible to just implement whatever extra components make up the Android system. To your points:
- Sandboxing: Android accomplishes this by running each app in the context of a different UID.
- No root access: Like above, user-installable apps are given separate UIDs. The GUI and other system processes probably also get random UIDs. Probably very little of the Android system runs as UID 0. (However, I don't really believe that keeping the user from doing things as root is a valuable security feature, as long as the user is competent)
- Verified boot: There's nothing specific to Linux/Android about this, right? The bootloader handles checking the signature.
- Hardware-backed key store: Isn't this, as the name implies, "hardware"? So it should be OS-agnostic, right? Maybe Linux doesn't use it, and Android does, but someone just needs to write a driver for it (and maybe some bytecode implementation or whatever, if it's some secure enclave thing, which it seems to be).
- User profiles encrypted independently: I don't think the Linux kernel supports encrypting profiles, this is a userland feature of Android, and could therefore be ported to Linux.
Note that this could include packaging Linux GUI applications as Android APKs (with some additional glue code and Wayland/DBus integration of course), so it's not even an either or.