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 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
Afterwards it's the job of UX design to package those features in meaningful ways. Maybe call the one "offline navigation mode", another "all comms off" (includes audio), etc. You get the gist.
1
The design of user-facing security features should be based around the high level semantics, not the low-level implementation details. What's useful to an end user is stopping audio recording, location tracking, etc. in a way that's robust against a deep compromise of the device.
1
It doesn't make sense to provide assorted features not actually achieving any goal. For example, disabling the microphone while having accelerometers / gyroscopes able to be polled at high frequently to act as decent microphones misleads users and isn't a working feature.
1
Come up with the desired semantics, then make sure they're provided. Implementation details first then trying to justify in a way that doesn't make sense isn't the way to approach it. Data can be exfiltrated later so that also needs to be kept in mind too.