Is Qubes resistant to forensics? I think its selling point is multi-level security and lateral movement prevention, not safeguarding data on a stolen laptop.

Hhmm that seems like a hassle, TBH.

One of the things I like the most about GOS is the web installer, and how easy it is to use. If I need a custom build, to run my own server, and sacrifice performance for it, it doesn't seem worth it. It would also be good to know what a debug build entails, how exactly it is "less secure", and so on. Since this is unlikely to be documented by the GOS team, a 3rd party guide would still be helpful.

Oh, I agree that the initial request is more than reasonable. Titanium Backup is something i miss every day.

Especially since Seedvault is.... ekhm, lacking.

> Designing a properly authenticated way to allow doing so would be an interesting challenge.

Qubes OS solved this problem. I don't see any flaws in their security model relying on vurtualization.

Yes but root still exists in phones just like it does in servers. It's just not accessible by the user. The OS does run processes as root and it needs it for things like updates.

Also, the user having root access doesn't mean that every process they run has root rights. For rooted phones there's apps to control what it's used for. Anything else just runs with the limited rights as before.

Of course those 'sudo' apps would be an attack vector but a pretty niche one.

I understand the risks, but just because they theoretically exist doesn't mean that they pose an active threat in all scenarios, or that they can't be mitigated.

The idea of locking the system down completely and preventing anyone from accessing it is technically more secure, but it creates many practical issues for tech-savvy people who want full control over their devices, which is the vast majority of the GrapheneOS user base.

If SELinux can mitigate the risks, then sure, let's use that. I don't really care what the technical solution is to this problem.

I'm just saying that:

a) As a user of an OS I want to be allowed full control over my device and not have babyproofed functionality because "it's for my own good". That is the realm of walled garden OSs from most major corporations which I deliberately avoid by using GOS in the first place.

b) My personal threat model doesn't involve using a bunch of untrusted applications, and I'm fine with trading some security for convenience. If the risks from choosing convenience can't be mitigated, then my OS should be flexible enough to allow me to make that choice. Other OSs can do this, so why can't GOS? I'm inclined to believe that there's no technical reason for it, but it's something that maintainers simply don't want to support. Which is fine, it's their project and their prerogative, but then let's not pretend that this is a discussion about security.