zlacker

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.

>>strcat+(OP)
Thanks for the thoughtful reply!

One of the advantages of hardware kill switches, shutters on cameras, and the like is social signaling: other people can see them, and can see them being used. If I put my mass-manufactured phone on the table, and you can see the hardware sensors switch is "off", you can be quite sure I'm not recording you.

I think there's a chance for us to normalize this sort of thing, and make it table stakes for a lot of interactions. In a meeting room and there isn't a shutter on the camera? That's breaking the rules and we need to find one. And so on.

Relevant to this discussion, another thought I had is location- and QoS-aware enabling and disabling of the cell radios so I'm using wifi whenever I can, automatically. If I have a good internet connection other than through the cell radio, the cell radio is shut off.

Thank you again for your thoughtful reply and your work.