Hacker News Reader

Comment by mentalgear | Hacker News Reader

This is especially interesting in regard to the recent HN dicussion on spyware by for-profit intel firms having access to Whatsapp, Telegram, Signal, etc. (https://news.ycombinator.com/item?id=47033976) through OS-level no-click hijacks.

I wonder how secure GrapheneOS is in that regard, and what the other contenders are?

View on HN

Hard to say how it fares against those specific attacks but some of the vulnerabilities that will go out in the mid-2026 on the mainstream handsets are already patched: https://grapheneos.org/releases#2026021200

(it's not magic. All big vendors have these details, just choose to take their sweet time to patch them. GOS has partnered with a major OEM vendor who provides them with access)

Other than the specific patches above, there's a list of generic GOS features: https://grapheneos.org/features#exploit-protection

All in all you're probably much safer.

GrapheneOS themselves dont pretend that their secure from that level of attack, but its about evaluating your own threat level. State sponsered actors aren't burning zero days on the vast majority of people, and you only need to look at how badly several european governments want to ban graphene and similar to see that such exploits aren't even being burned on organised crime. Realistically unless you're a journalist or considered a political target you're gonna be fine with graphene.

Thank you for the insight. Indeed, a concerning state of the world where criminals are less at risk from spyware than journalists and activists.

Its definitely a scary world, safe to assume all your online activity could be hacked if so wanted. Just gotta hope its not wanted and that it doesnt become possible to do it on a mass scale (UK is currently pushing to ban E2E lol, and I know the EU has contemplated similar. If you do fall into the wanted category, face 2 face is really the only option. I know a lot of politcal/investigative journalists also constantly cycle and maintain burner devices but even thats a risk of just how long is a safe time before a device is considered burned.

GrapheneOS have hardened_malloc which is a huge advantage, I think. It makes the weird machines problem much harder. I would say be very careful, because you can still get previews of images, or old and weird media formats that could be exploitable, and android/GrapheneOS doesn't have the same sorts of policy as say Apple with the iMessage blast door. They control safari, etc.

Android's attack surface seems pretty jagged. For example there is only one webrender engine on iOS, where you can run anything you like on Android/GrapheneOS.

Chromium is the only web engine present on a fresh install. If a user doesn't install a browser with another engine, the attack surface doesn't get increased. Chromium/Blink is more secure than Safari/Webkit overall so I don't really think this is an argument in favour of iOS. iOS for sure does some good things though and is better than Android in some areas.

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.

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.

> well, a concerted attack could easily subvert the baseband

In theory Pixel phones have IOMMU and GrapheneOS is using them, so even a compromised baseband doesn't result unrestricted access to the system.

GrapheneOS distrusts the network. Connections use HTTPS and the integrity of important things like updates is also verified via signatures.

Interesting. What are the alternatives to GrapheneOS that you wouldn't consider a "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.

If the open hardware offers at least comparable security then maybe. If the hardware is an open book then no.

A short list of the hardware security measures necessary to consider it "not a toy" ;) -- https://grapheneos.org/faq#future-devices

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.

x86 virtualization isn't perfect at all

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.

> x86 virtualization isn't perfect at all

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.

If you choose open platform with barely any hardware security measures then indeed, no questions from me either :)

Which security measures? I do have TMP with Heads.

Let me list several of the more impactful.

- dedicated, certified security coprocessor (Titan M2) - on pixel it's fused with verified boot, offers key storage, firmware isolation and anti rollback.

- verified boot: mandatory and backed by Titan, immutable boot from. Almost all laptops lack as much as anti rollback.

- strong hardware-backed key protection and actually isolated TEE. Yes, I know about Intel (SGX/TDX) and AMD (SEV/SME). Broken into many times over. How many commodity hardware devices offer comprehensive protections like Titan-backed TEE?

- secure hardware-backed disk encryption key derivation (with throttling of course)

- on-device attestation: complete verification of the entire chain. Dreaded Play Integrity or open AOSP / GrapheneOS hardware attestation. Which PC vendors can offer that? Perhaps Apple but that's not a pc and you won't run qubes on that?

- physical anti-tamper: which laptops wipe encryption keys stored in the secure hardware when you're trying to unlock the bootloader?

- physical memory tagging (see ARM MTE). Apple offers some but again, that's not for qubes. Intel promises MKTME in the future.

- does your laptop disable all the unconnected ports whilst the laptop is broken? Does your pin/password verification happen inside TEE/TPM, not in the OS?

- modes similar to PXN/SMEP, SMAP/PAN (to stop these pesky wifi/gpu firmware from reading userpace memory). There's some support for SMEP and SMAP on intel/amd

- microcode and firmware upgrades velocity

There are reasons GOS doesn't support any hardware other than pixels. Regrettably and thankfully that is about to change soon <3

Don't read me wrong, qubes is brilliant and on SOME hardware (business grade laptops with TPM 2.0, verified firmware upgrade process with some protections and proved track progress with rapid hardware drivers and firmware upgrades -- sure, brilliant choice. For pcs.

But is not even remotely close security-wise..

Best available would be probably Purism Libre (lacking TPM if I read it correctly, weak hardware but, oh well, pixel is not super fast either lol), or something with coreboot perhaps?

Whats the safest and still useful laptop hardware you cna think of? Let's compare with with pixel.

Thanks for the detailed answer. Librem laptop is exactly what I use, with TPM and a hardware token. Also with Qubes OS.

There is no way to know whether the phone you buy corresponds to the open schematics that are published. It's not verifiable like with software.

This doesn't sound right to me. Not an expert, but I saw many discussions confirming that this is possible.

So if a toy OS is the only one to withstand attacks with Cellebrite, what do you consider not a toy?

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.

It's just an Android fork. Almost certainly it's equally affected.

That's too simple. First of all, Pixel (which GrapheneOS requires) is one of the few Android phones with a separate secure enclave. GrapheneOS also applies a lot of hardening that other vendors do not: https://grapheneos.org/features#exploit-protection

This does make a material difference, e.g.: https://x.com/MetroplexGOS/status/1982163802188575178

That said, if a state-level actor is up against you, then it's hard to defend yourself against that.

Reply on news.ycombinator.com