Initially, it doesn't need to be better. It's difficult enough to produce a device meeting the same standards without severe privacy or security regressions. We're not interested in having our brand associated with a device that's marketed as private and secure but is worse off.
Conversation
The setup we want to have isn't far from what Google was doing with Nexus devices. GrapheneOS needs substantial input into the design and implementation of devices. They'll use our signing keys for boot chain, stock OS verified boot key, etc.
Pixels set the baseline standards.
1
2
32
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.
5
6
38
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 baseband and other radios on the currently supported devices are isolated: grapheneos.org/faq#baseband-i. That wouldn't be an additional feature. That's part of the baseline that has to be preserved. Expectation is also that the radios would be equally hardened as the status quo.
1
1
For a hardware location kill switch to work properly, it has to do a superset of what the 'Sensors Off' kill switch provides and has to disable all the radios in addition to the GPS. It makes more sense for that single switch to have 3 states rather than pointless complexity.
1
Features need to be designed around the desired semantics and implemented in a way that achieves it. You should be focusing on what the kill switch is supposed to prevent when the device is compromised like preventing location detection and then determine what it has to disable.
1
Disabling GPS doesn't do that. Disabling GPS + radios doesn't either. Can still determine location via other methods. The assorted sensors can be used to track direction (compass) and movement which can then be used to determine location. Audio is being used for location too.
1
Playing and recording audio outside the range of human hearing is used to communicate with beacons. Look up ultrasonic location tracking. The location kill switch probably has to kill speakers too, so it's a superset of 'Sensors Off' also including speakers + radios + GPS too.