Let's see, the root filesystem is read-only with tamper-proof authentication, user's home directory is encrypted.

Chrome runs with the usual privilege separation in multiple processes each in it's own tight sandbox.

There is no way to autostart anything.

Even in the nuclear case of a 0-day RCE + chained sandbox breakout + privilege escalation to root, the threat can not persist itself... you just reboot the device and are save again.

And the list goes on...

Their crosvm VMM puts every emulated piece of hardware in it's own isolated process[1]. The drive emulator is blocked from even open files itself.

Google has lot's of experience in security, they are one of the few who still build their own browser, the most hostile environment.

[1] https://crosvm.dev/book/appendix/sandboxing.html

ChromeOS is Linux, as it's running the Linux kernel. As is Android for that matter. But anyway, Google doesn't let you run random binaries you download on ChromeOS, outside of a limited sandbox, making it more secure than a distro that lets you run curl | sudo sh outside of a VM.

There are some other security shaped things they do as well.

https://support.google.com/chromebook/answer/3438631?hl=en

Here is an incomplete paper that gives a 50,000ft overview: https://www.chromium.org/chromium-os/developer-library/refer...

The average Linux desktop does not even come close to having a design as thorough as this, much less a full-blown, actually usable implementation of said design. Frankly, 99% of Linux desktop installs used by developers I've ever seen are nothing more than single-user systems with everything running under a user account that is morally (and in practice, technically) equivalent to root.

The bar for desktop security in the Linux world is actually very, very low.