zlacker

>>wicket+(OP)
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.

>>codeth+sZ
What nonexistent security model? Isn't Android just stock Linux with an interface layer on top?

>>phendr+cD5
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.

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

- …

>>codeth+2Q6
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.