I'm not saying yours works when it doesn't, but there may be something else going on.

FTFY!

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.

Still though, when it gets to the point where we're using "Designed in California" as a source of security comfort, things are bleak.

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.

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

Again, I get the human factors appeal of physical kill switches, and if all else were equal they may be worth having, but people are place far too much faith in the value of physical kill switches.

Same strawman as earlier: I already replied that I never said that Librem 5 was more secure. At least you accepted that the kill switches do work, so there is progress.

> If they are approximately equally effective then you have given up a lot for no benefit, and are net much worse off.

(I won't claim they are, but) there is another benefit in freedom, apart from the security. Some people care about freedom. When I see that, I suggest Librem 5 in my replies, and not as a more secure solution. Maybe you should read my replies more carefully before answering.

The line of thinking is, if you're so concerned about your device being compromised that you need to enable the mic kill switch (because of aforementioned lack of trust in the device), then other sensors which have been demonstrated to be able to capture audio can't be trusted, either, and in many demonstrations some of those sensors have been shown to be capable of recording what is effectively audio. That's old news, so you shouldn't have any difficulty finding evidence of your own.

On a device that's that compromised one would have to physically power off every sensor on the device, and even then there would still be some things to consider. Air gaps are a thing for a reason, and yet some incredibly clever exploits have been demonstrated to jump that gap. Many components that aren't microphones, cameras or radios can be turned into cameras, microphones or radios pretty effectively.

Still, I see the appeal of hardware switches as another practical layer against basic human factors, like a webcam lens cover adding another step beyond firing up the camera's permissions/appVM. But if we're being practical, a phone I can get wet is much more practical than a phone with physical hardware switches when I already have a high degree of trust the OS's ability to control sensors, and a low degree of rust in the OS's ability to control liquids and debris.

> Which was freed and can run new Linux kernels now:

Unfortunately that has kernel dependencies that haven't been updated in years. If you think the kernels in well-maintained Debian and Fedora VMs still need to be separated by a hypervisor to be trustworthy, you're in for a bad time trying to run that kernel on a PinePhone.

> Your walls of text are disingenuous.

You've got the attention of one of the sharpest security minds on the planet and that is what you come up with?

"Unless you provide some evidence, I will consider this false accusation." is bizarre, especially given your audience. You're capable of learning all this stuff on your own without asking everyone to do that for you.

Regardless, nine sentences across two paragraphs isn't a wall of text. The guy took time out of his day to respond to banality and that's what he gets.

It's becoming increasingly difficult to see you as anything but someone who deliberately attempts to derail any threads relating to Graphene OS. Help me out: why shouldn't I?

You (and strcat) have no idea what you are talking about. And you are constantly shifting goals. Sensors are much harder to use as microphones. Was it ever caught in the wild, not in a lab? Sensors are also switched off on Librem 5 by the three kill switches: https://puri.sm/posts/lockdown-mode-on-the-librem-5-beyond-h...

> If you think the kernels in well-maintained Debian and Fedora VMs still need to be separated by a hypervisor to be trustworthy, you're in for a bad time trying to run that kernel on a PinePhone.

This is misleading. There are different degrees of security. Qubes provides the highest achievable degree (for certain threat models). It doesn't mean that Debian and Fedora have no security at all. Moreover, if you only run trusted application, they are reasonably secure, unlike OSes with (partially) closed source.

> You've got the attention of one of the sharpest security minds on the planet and that is what you come up with?

I don't care about personalities. Famous and smart people are wrong more often than you seem to think.* I care about arguments. This is why I'm on HN.

> Regardless, nine sentences across two paragraphs isn't a wall of text.

I am talking about all comments together, not one comment.

> It's becoming increasingly difficult to see you as anything but someone who deliberately attempts to derail any threads relating to Graphene OS. Help me out: why shouldn't I?

I do not have any hope that you try to understand me, since you immediately started fighting with me, without even considering my point of view. Many of your replies (see example in this very answer of mine) did not address my concerns. Some of your replies ignored my links (LoC).

* (Me included; I argue here, because I want to find out where I'm wrong.)

The trusted application thing is hard, same as the trusted kernel thing is hard. Some monolithic kernels are adding bugs faster than they're being addressed. It's a really hard problem and I don't see monolithic kernels as being the best solution of the future. That's relevant to threat modeling, which is why virtualization is so valuable, but it needs to be built on a secure hardware platform. Part of the benefits of significant sandboxing, much like virtualization, is you can ultimately run all apps as some degree of untrusted. Both together would be best. Saying you can't imagine how something could be more secure than your Qubes setup is a better indication of your ability to imagine than it is of any security reality. And then you recommend people check out two solutions with the benefits of neither approach (and other issues).

Anyway, I'm still going at this because your comments (which frequently commit the errors of which you accuse others) go unreplied in too many threads, so I engage so that others who skim threads containing questionable assertions will at least see a different viewpoint.

When I recently didn't continue to play along with you, you tried to use that thread as evidence supporting some kind of weird dunking on me, and others. It's a project you claim to care about and want to see succeed, and then you repeatedly approach it in a highly insufficient way, often invoking the project in threads not even about it just to go ahead and dismiss it. You ask basic, easily researched questions relentlessly and when people stop answering point to the lack of a final response as justification, despite your claims of awareness of your own ignorance. There's an actual name for what it is you're doing.

It's a weird axe you have to grind, and I'm content to let others see it all in context and decide for themselves. I only bother because I think it's an important project, genuinely want to see it succeed, and think on this important site of tech culture, you're damaging it unfairly. Whether that's intentional or not, I don't know, nor do I need to.

So you confirm that you and strcat were spreading false information about Librem 5 with a convincing tone, while saying that you're "sharpest security minds on the planet" and calling me "disingenuous"?

> Same as if you turn off all radios and sensors on a GrapheneOS device.

This is plain false. Software switches can never be as secure as cutting power from hardware components. Are you saying that GrapheneOS can reliably save you from tracking by a state actor? This is very unlikely. The number of lines of code in Trusted Computing Base of GrapheneOS is likely similar to one in the monolithic Linux kernel (10 MM lines of code, https://doc.qubes-os.org/en/latest/developer/system/security...). (I would be happy to be corrected if I'm wrong here.) This is why it can never be as reliable as hardware virtualization relying on 100000 LoC. I'm happy that GrapheneOS is going to add the virtualization btw.

> Saying you can't imagine how something could be more secure than your Qubes setup is a better indication of your ability to imagine than it is of any security reality.

You walls of text are so large and not always constructive, because they frequently contain personal attacks like this one (and words like "disingenuous" I mentioned above).

> You ask basic, easily researched questions relentlessly

If this is so basic, I don't understand why you are making so many false or implausible claims and do not just give me a link with a simple, high-level explanation for noobs like me. Instead you keep attacking me and presenting yourself as very smart, with words like these.

I agree with you that GrapheneOS is a very important project. I disagree that trying to point out its weaknesses or ways to improve it harms the project. I also would like to add that Librem 5 is similarly important project, and you unnecessarily harm it with your false claims. Some people come to discussions about GrapheneOS asking to get root of rely more on free drivers, or expand the supported devices by lowering security requirements. My replies about Librem 5 to these people do not harm GrapheneOS, since they aren't your target audience anyway. I just help them to find what they want.

If you don't think voting with your wallet works, then that is a position you can take. But you can't think it works when buying from the OEM but doesn't work when buying on the secondary market.

And ultimately, if buying it on the secondary market in such small numbers that it doesn't move the market, then it adequately addresses the concern.

Edit: I'm not saying there's zero effect of it, but it's likely statistically insignificant.

Since then:

> In Android 16, Google expanded the "Linux Terminal" feature, which was initially introduced in Android 15 QPR2 beta, allowing users to run Linux applications within a virtual machine on their devices. This feature utilizes the Android Virtualization Framework (AVF) to create a Debian-based environment where users can execute Linux commands and graphical applications. The guest operating system is fully isolated by the hypervisor (KVM or gunyah) and manages its own resources with its own Linux kernel. Notably, it supports running classic software such as Doom, demonstrating its ability to run full desktop applications.

> and Graphene is under no obligation to provide anything to anyone.

And here I thought it felt repetitive between (sub) threads

I simply agreed with the person who posted this sentiment by mentioning another place where an organisation acts contrary to its stated goal (Signal wants privacy, but also your phone number? I can come up with reasons like that it costs money and thus helps against spam, but it's still at odds and different solutions and opinions are possible)

If someone comes to one of my open source projects' bugtrackers and says "I want you to implement X", I can say "enjoy implementing that", or I can say "this is a bad idea because reasons". GrapheneOS does the latter. Responding to that, waylaying arguments, is not the same as demanding free work. They're free to not care

People who spend huge quantities of time trolling somebody who makes an excellent mobile operating system are really quite something. I used to think he was overselling the quantity and quality of it, but this post's comments have really turned me around on that one. So: thanks for that.

It does bother me that I spend time answering in a clear way, since apparently it wasn't clear previously so I spend more time, and then it gets dismissed as disingenuous flamebait, or whatever the definition of trolling is

¹ (Not sure, as a non-native speaker, but to me that word sounds like there might be a material objective beyond coming to a common understanding. I don't have such an ulterior objective. If I'm right about that connotation then please read "point" in place of this word)