Hi daneel, what would you like GrapheneOS to do while you develop your own formally verified, open hardware, open source firmware/OS baseband processor they can use? Sit on their hands doing nothing or making the best of the least worst options currently available?

The Pixels already are the best of the least worst options currently available. Anything new must categorically bring improvements, and the closed source firmware of the Pixels is a pressing point.

That's reasonable, and I hope we get there.

Qualcomm is an American company, and it sounds like the GrapheneOS team is working directly with them on developing the spec for this, including hardware MTE support. That's promising and I think could bring improvements over the current situation, if not open source modem firmware, unfortunately. I'm hoping to be surprised, though.

> Neither you nor GrapheneOS users have any idea at all what's going on in their cellular transceivers

Pixel has an IOMMU - are you implying that’s being defeated, or that you weren’t aware of it?

Neither. It's great that the Pixels' baseband ACPU doesn't have free reign in system memory, but if we're gonna underline the deficient state of the cellular modem in the Pine Phone we should also remind ourselves that the firmware situation with the Pixels is an almost equally sore thumb.

It doesn’t feel equal to me, here in my real-world usecase.

There's a lot of hand-wringing in this thread about Motorola's location, and a lot of support from a few for a modem made by a company headquartered in....Shanghai. If consistency here is what we claim to be pursuing, then let's actually pursue it.

The opacity of the firmware situation isn't great on either, but one contains numerous excellent mitigations and is very proactively maintained, and the other is something that relies heavily on reverse engineering and community projects to even use.

And it has a physical switch and has some physical distance between it and the CPU, both of which given the previous limitations are mostly theater, in practice. "My modem is so vulnerable it needs to be turned off during extra-important times, but I don't mind leaving it on during times that are merely important." As if a compromised OS can't just wait to exfil data. If your goal is to make it to Checkpoint Charlie and don't want the hassle of having to buy a new phone after you reach freedom, fine, but I haven't seen many well-articulated needs that would be satisfied by a hardware switch when everything behind that switch is filled with vulnerabilities.

For my threat model, using the modern modem with a bounds sanitizer, an integer overflow sanitizer, stack canaries, control flow integrity, automatic initialization of stack variables, very active updates and a large commercial user base and a large market cap in part depending on it, makes a lot more sense.

Google's highly lucrative ad tech business is what makes everyone nervous about anything Google, rightly so, but their share price would plummet if they were caught using Pixel hardware in nefarious ways, or did an unreasonably insufficient job in securing it. I'm not saying it's not possible that the modem is compromised, but for my threat model I have to put a lot into the possibility of an undetected backdoor inside a modem which is by all indications constructed very well, to make using a weird old modem known to be massively lacking in dozens of ways, running an OS with all kinds of issues, make more sense.

And I say that as someone who tried the PinePhone at one point. Fun idea, but no commercial or state organization with an elevated risk profile would trust their data to a PinePhone as it stands. It's fun for hobbyists, but it doesn't belong in the conversation with iPhones and Pixels from a security standpoint. It won't be making it onto the DoDIN APL any time soon.

> As if a compromised OS can't just wait to exfil data.

How can a compromised OS exfiltrate any data that was never collected?