It's quite secure against casual attacks, but a proprietary mobile platform has inherent issues wrt. withstanding even mildly sophisticated attackers, including mercenary spyware services. You still have a huge attack surface from all sorts of proprietary firmware blobs and hardware IP blocks that are running directly on the SoC. It's not clear that it's really worth even trying to secure it as opposed to just treating it like an untrusted toy.
In my understanding, it's not the OS that makes it a toy but the hardware. I guess something with open schematics (Librem 5, Pinephone) should be better, or an open-hardware device like Precursor.
I'm not convinced that all of these is required for security. My Qubes OS desktop is probably more secure than any GrapheneOS phone, and it only requires good hardware virtualization for that.
> If the hardware is an open book then no.
So you choose security through obscurity. I have no further questions.
QubesOS certainly has some good things going for it with isolation but the guest VMs which run traditional desktop OSes are generally much less secure than mobile OSes like Android OSes and iOS
Iirc it's not even possible to run QubesOS on hardware that has proper verified boot or non-meaningless secureboot.
With regards to security through obscurity, the Pixel firmware isn't obfuscated at all. It's closed source but it's easy to decompile the code and inspect it. They don't try to obfuscate it to make that difficult.
You cannot just say this without any links. Last escape from VT-d virtualization, which Qubes uses, was found in 2006 by the Qubes founder ("Blue Pill").
> Iirc it's not even possible to run QubesOS on hardware that has proper verified boot or non-meaningless secureboot.
You can run Qubes OS on something even better: Coreboot with Heads and with a hardware key. All based on FLOSS. Works for me.
> but the guest VMs which run traditional desktop OSes are generally much less secure than mobile OSes like Android OSes and iOS
First of all, you can in principle run any OS in Qubes VMs, including hardened ones. You can even disable the root account. Second, with such statement, you misinterpret the Qubes' approach to security. You isolate trusted workflows from untrusted ones, which gives you the strong security. You never open anything untrusted in trusted VMs, so their internal security plays no big role.
well, a concerted attack could easily subvert the baseband if you have a few million dollars and the correct letterhead or private contacts.
GrapheneOS really wants the software in the phone to not pwn the phone. This is good. Its a different, and much more difficult problem to secure the connection to the telco, and the larger internet, because the transport is attacker controlled.
Think of it this way: Say you use Qubes because security is valued very highly for you. Even if you run Qubes, if your router is controlled by your attacker, what kind of a security guarantee could you really get for yourself?
> Even if you run Qubes, if your router is controlled by your attacker, what kind of a security guarantee could you really get for yourself?
I do run Qubes, and a compromised router, e.g., will not get access to any passwords that I store in an offline VM as text, even with any previously known vulnerability since 2006.
The firmware being proprietary is compeltely unrelated to how much attack surface it has compared to open source firmware. The only thing that matters is how secure the firmware is.
