Can't edit my other reply.

Edit: I looked at your other comments to see if you had discussed Linux or Android security before (and to avoid repetitive threads). I'll reply to this post of yours here as you'll likely not see that I've replied there:

> Also linux only really has block level encryption, not file based encryption like iOS/Android. It would be trivial for LEO to access your device unless it was totally powered off and then the only protection is LUKS. Or really even if you lose your phone and someone was so inclined to they could just extract all the data if it was powered on but on the “lock screen,” as most if not all desktop (and I’d imagine linux phone) environments do not actually do any encryption or anything when the system is locked, it’s just a cosmetic lock for all intents and purposes.

With LUKS or plain dm-crypt unencrypted data never touches the storage. Small parts of the storage are decrypted in RAM, but what gets written is encrypted. FDE at the block level gives less info to the adversary than file based encryption. With detached /boot (and maybesome other stuff) (like on a USB stick), and plain dm-crypt, you can even have plausible deniability that the storage medium was just overwritten with random data. LEO can't do anything for LUKS or dm-crypt if they can't bypass the lock screen, short of a cold boot attack. That's true for file-based encryption, too. The lock screen (on Linux, at least) isn't related to disk encryption and doesn't have to be.

I don't agree with you, but I appreciate the time you took to reply. Apologies if I may appear terse.

> The security models of desktop operating systems are far, far behind those of mobile operating systems

What about Qubes? That's my standard. Everything else has worse security almost by definition (since you can virtualize it and increase its security that way).

> The first sentence is inherently incompatible with the security structure of GrapheneOS (for example).

My mistake - sorry. I wanted to say something like:

> I would choose something as locked down as GrapheneOS (no root) for its security if I were to use it to install random apps or to run JS from random sites - examples of exposing myself to unnecessary danger like someone who doesn't know what he's doing. I would choose something with root but wouldn't run random apps with root permissions or JS on a browser started with root permissions.

I somehow mixed both sentences when editing.

> it doesn’t matter if you’re only giving “trusted” apps root, all it takes is one supply chain exploit, one malicious developer, one anything to make that app with root do something its not supposed to do.

That's where we differ on our views of security, agency and responsibility. I own the computer so I should be able to give root to whatever I trust. I already trust the the hardware, the myriad of developers writing the OS, the libraries they've used and so on. Yes, trusting less things is better, but there's a tradeoff and we can easier restrict the OS further and further until we're left with nothing. The OS shouldn't restrict what I can trust and what I can't trust. Why is the OS trying to force me to not trust any app but only the millions on lines of code of the OS itself and the hardware?

> The point is to not give applications root, giving them root circumvents basically all of the protections GrapheneOS and Android give the user.

Giving all applications root might circumvent all protections in GrapheneOS and Android. How does giving 1 application I trust circumvent all protections? Let's say I wrote the app (and I trust myself) and then formally verified it - just for the sake of argument. Although I'd give root to apps I didn't write or verify because I am an adult who can choose what code to trust. We already have important information and already give important permissions to apps that, if compromised, can ruin our lives easily (browsers, communication apps and so on).

> The problem is that we don’t know how they could leverage it, so the solution is to eliminate that pathway entirely.

So apps are both sandboxed and there are robust permissions which make Android much more secure than most desktop OSes, but we can't even give an app root because it might somehow wreck the whole system? I don't get this. By that logic we don't know if any app could compromise any of the system processes that have root (or functionally equivalent access). The solution would be to not run untrusted apps in the same OS at all, to have different computers or some hardened virtualization like Qubes? I get that it's not black and white, but my hypothetical terminal app with root permissions won't be the only process with root permissions running on the OS, so why is it THAT bad to give it root? Especially when I'd run it with root only for certain tasks, just like I don't "sudo ls ~" but just "ls ~".

> This is also my issue with the push for Linux phones onto the average person (instead of the community coming together and forking AOSP if they want to escape Google). The platform has zero real sandboxing, and the average person still wants to use Meta apps as shit as they are. These big tech companies’ and governments’ apps would go absolutely crazy on Linux phones.

Why not try to use existing security mechanisms in various Linux distros (or Qubes) to prevent Meta's apps from going crazy? Additionally, why can I load facebook.com in Firefox on Linux and be relatively certain I won't get pwnd by Facebook even though I have root on Linux? That would mean we trust browser sandboxing more than Android sandboxing. Yet we have root on Linux and can do anything with the browser. What I mean is, you state that Android is so secure, yet we trust it less than untrusted JS on a browser on desktop. If we don't, should we disallow people to run JS (or even CSS, as there have been attacks via CSS) at all?

> my view is that we shouldn’t be pushing root-capable mobile operating systems onto the average person

My view is that we should default on root-capable devices for anyone. If a user doesn't feel sure in their abilities, they may select "I am not sure of my abilities to operate a computer, lock it down for me permanently" option. Otherwise it's on them. We shouldn't be nannies for people. People will eventually learn when enough people get burned. We should be nannies for obvious cases of mental retardation where the person requires round the clock care, but not for everybody. We're not sheep and shouldn't all be treated as sheep even if a lot of us are.

> Also preventing root allows devices to pass attestation checks. I know it has a dirty connotation in light of how companies are behaving recently, but it really is a security benefit for a device to be able to prove that it’s base operating system is unmodified (i.e. no persistent malware is present).

I might see a benefit for workers in a company for work-provided computers because they're company owned, but any attestation for user-owned computers that is imposed on a user will almost inevitably lead to a dystopian future where computers get more and more controlled, locked down and even backdoored without a way to even see if they are. For example, in many jurisdictions you're required to have phone, to use Android or iOS, to have an account with Google or Apple, to not have root and to not run a custom ROM in order to use basic public services or banking (even if my bank account has like 5 bucks in it and I wouldn't care less if it got hacked). That is absolutely wrong and if we don't do something it's going to get much worse in the future. We should fight these restrictions whenever we encounter them. We the people own our lives - we should own our computers and we should own (as in responsibility) our choices.