Some additions to the secure element APIs would make sense and a 'Sensors Off' switch disabling all sensors usable for audio recording (microphones, cameras, gyroscopes, accelerometers, compass, barometer, etc.) for mitigating a compromised device would be a nice frill to add.
Conversation
Replying to
individual switch-off for baseband, wifi/bt, gps, mic/sensors would be nice. Isolated and easily replaceable baseband as well (to update the imei). sign me up for something like that ...
1
2
2
Other sensors can be used for recording audio. The purpose for 'Sensors Off' would be preventing audio recording when the device has been compromised.
It's not clear what you would expect to get from those other switches and we won't do any security theatre. See the next tweet.
1
4
twitter.com/GrapheneOS/sta
Any added features need a meaningful threat model and implementation. A GPS kill switch doesn't come anywhere close to preventing location detection.
On most phones, detecting location is typically done with cellular and Wi-Fi first. GPS kicks in later.
Quote Tweet
Some additions to the secure element APIs would make sense and a 'Sensors Off' switch disabling all sensors usable for audio recording (microphones, cameras, gyroscopes, accelerometers, compass, barometer, etc.) for mitigating a compromised device would be a nice frill to add.
Show this thread
2
3
The GPS-off vs Wifi/Baseband off is that all three methods are different thread models. Wifi (and cell ID) are for evil apps, baseband is for evil network ops/ss7 etc. The main point with wifi/bb off is to be able to use GPS for navigation without broadcasting your whereabouts.
2
All of those can already be turned off already on the currently supported devices. The purpose of a kill switch is that it works after the device has been deeply compromised. Our features need a proper threat model and implementation. What you're saying just isn't how we roll.
2
Well, I was always telling you what kind of device I would buy (and a couple of others). Apart from that, the whole thing is called defense in depths: When the OS security has been penetrated, I STILL don't want to care if some privint dude can check my location history via SS7.
1
That's not defense in depth. It's called security theatre. Providing features that do not actually work and do not provide meaningful security semantics misleads users and can result in them making bad decisions based on the false sense of security being provided. Not what we do.
2
Well... minus one sales. And maybe reread what I actually wrote. Good luck and carry on the good work.
1
I understand what you wrote. It's not how we do things. As with every other privacy and security feature we work on, we'll approach kill switches based on providing meaningful security semantics. We don't add assorted frills that do not provide useful security properties.
1
1
It doesn't make sense to have a microphone kill switch where you can still record audio by using the speakers or using high frequency polling of motion sensors as a makeshift speaker. An *audio recording* kill switch is what actually makes sense. Same for other things too.
It's a user interface provided to end users. It should provide meaningful semantics. Hooking up assorted components to a separate kill switch without actual security semantics provided by them is not how we do things. We'll do this as we do other things.
1
If that's not what you want, it doesn't sound like you would be interest in how we do anything else either. We consider stuff like twitter.com/GrapheneOS/sta and we don't try to provide something unworkable or that harms users rather than helping them. Same for the OS and hardware.
Quote Tweet
If an app has the ability to perform arbitrary DNS queries via the OS, it can exfiltrate data to any party.
It can query encrypted-data.domain.tld to send data to an authoritative DNS server. No direct connection is ever required. It's being used in practice. Keep that in mind.
Show this thread