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.
> Why not try to fork AOSP or GOS
Which concerns do you share? Both AOSP and GOS must follow the Google development strategy, they aren't exactly independent on Google (which is a problem: >>45208925 ). Nevertheless GOS on Librem 5 or Pinephone would be a nice idea, except the GOS developers are against that: >>45101400
> Linux's (nonexistent) security model
Linux's security model is based on trusting the software you're installing from the FLOSS repositories, and it works very well.
That's not a security model, and we don't live in fairyland.
Just take a look how well this works with npm packages. It just so happens that emacs plugins are not the most worthwhile target for attackers.
This has nothing to do with what I said. npm is not a trusted or a FLOSS repository.
> we don't live in fairyland
When did you see a malware in Debian's repositories last time?
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.
> 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.
https://dl.acm.org/doi/fullHtml/10.1145/3448609
And then there's also:
- No root access (by default)
- Verified Boot
- Hardware-backed key store and hardware attestation
- User profiles are encrypted independently of each other
- …
- 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.