zlacker

>>moelf+(OP)
I think GrapheneOS is one of the most important projects going. Many people walk around with all-purpose spying devices in their pocket, oblivious to how much power they are giving up. They have no control over these devices, and they don't even understand.

GrapheneOS gives us a way to resist. The convenience of having a modern phone is hard to give up, and with GrapheneOS you can have 90% of that convenience while reducing much of the surveillance and attack surface. Now, we just need a pixel phone with two big hardware switches, sliders on each side of the phone: one kills the radios, and the other kills the sensors (cameras, microphones). When you want to take a call, just flip the big slider switch up to activate cameras and mics.

Thank you to strcat and the rest of the team! If you don't use GrapheneOS, I would consider it. You can donate here: https://grapheneos.org/donate And if you have the right kind of programming skills, why not help out?

>>NoImma+FR
We plan to include a sensor kill switch on our own future hardware but the value is lower than most people believe on one of their primary computing devices. If it was successfully exploited, an attacker would get all of the data including documents, photos, videos, browser history, login sessions, passwords and much more. They'd also have control of the sensors whenever they're enabled including any calls, etc.

A kill switch for all of the radios is much less useful for this threat model because even regular apps know how to queue up all their data for later usage. If the goal is preventing detection location detection, that really requires disabling all the radios and sensors rather than just radios. If the goal is dealing with an attacker able to exploit radio firmware but not the OS from there due to the IOMMU isolation and hardened kernel/userspace drivers in GrapheneOS, that could potentially be useful, but they'd already lose access on a reboot as long as it power cycled the radio as long as the radio doesn't have any significant persistent state due to verified boot.