[Itoldmyselfso]

1. It's not possible to root GrapheneOS or any Android-based OS and preserve the Android security model. That would run entirely counter to the goal of the GOS. It can be done but shouldn't.

2. They have implemented kill switches for these on the software level. Afaik there's nothing up dispute these working just as well as hardware switches assuming proper verified install of GOS.

[bgbntty2]

1. I've read that rooting breaks Android's security model, but I have yet to find a detailed explanation of how it actually lowers Android's security, especially compared to desktop OSes that are usually rooted, like Linux or MacOS.

2. Software kill switches are prone to software attacks, aren't they? They can't be as secure as hardware kill switches unless we can prove the software kill switches can't be attacked by software. I doubt anyone can prove this.

[fc417fc802]

Approximately, if the user doesn't have root then there's no way to trick them. They also can't access internal app files which gives app authors tight control over how their software is used.

That's the security model. Giving users root breaks both of those assumptions, hence it breaks the security model.

Notice that it is clearly in the best interests of users to at least have this option. But modern BigTech operating systems are designed around corporate interests, not yours. And security professionals seem to prefer to ignore inconvenient things like user freedom.

[bgbntty2]

> Approximately, if the user doesn't have root then there's no way to trick them.

So not having root (somehow?) prevents phishing and tricking? That doesn't seem useful or relevant for people who know what they're doing. If I'm wrong, please elaborate.

> They also can't access internal app files which gives app authors tight control over how their software is used.

I read that in the security model and I don't care for it. App authors shouldn't have any control over how their software is used. In my opinion, of course, but for my computers my opinion is what matters.

[fc417fc802]

I agree with you of course. The thing I find frustrating is the willingness of the GrapheneOS (and to a lesser extent LineageOS) devs to toe the corporate line, accepting anti-user-freedom bullshit in the name of this non-security.

> trick them [ into granting root ]

Apologies for the ambiguity.

[palata]

> how it actually lowers Android's security, especially compared to desktop OSes that are usually rooted, like Linux or MacOS

Mobile OSes are notoriously more secure than desktop ones, precisel because of the security model.

[bgbntty2]

Okay, but could you give me some examples? How is Android or iOS more secure than Linux or Qubes?

[palata]

Android/iOS do sandbox user apps by default, for instance. When you run a script on Linux, it has access to everything your user has.

Access control is also more advanced, e.g. apps need to request permissions to the user. Not saying that desktop OSes are not making progress, but they are behind.

I don't know if Qubes qualifies here. Qubes runs Linux instances in VMs to compartmentalise them, but then each Linux instance has the Linux security model.

[bgbntty2]

I agree with the sandboxing and permissions points, but is that related to the OS not being rooted? This is a genuine question - I'm not trying to make a point here, but to learn.

I think Qubes qualifies from a practical point of view, as modern hardware is powerful enough for it, so it's viable to run Qubes on desktop instead of a baremetal OS. I'd even go further and say there's no excuse not to run Qubes if you're familiar with Linux and can afford a compatible desktop or laptop.

Per-app sandboxing or per-OS compartmentalization is pretty similar with regards to security. There are some security and usability trade-offs, but I like the per-OS isolation model, as it's easier for several apps to share everything within a VM - that way you isolate a whole "project" more easily, as everything inside a VM is only related to that project and you assume all the apps would need access, anyway.