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
does it mean that on Pixels + GrapheneOS, when an app has "sensors access", it has an indirect access to audio recording, even if if microphone permission is off ?
1
Sensors like gyroscopes and accelerometers can be used for recording audio. Android doesn't give apps high frequency polling of sensors and limits their usage in the background: developer.android.com/guide/topics/s.
The kill switch threat model is that the device has been compromised though.
1
That means for the kill switch threat model, there is no limitation on polling sensors, and they make much better microphones than they do with that limitation. Even with the limitation, they can perform crude audio recording. Sound is vibration. Gyroscopes, etc. are crude mics.
1
Custom hardware isn't going to change anything about the permission model used in the OS or the semantics for it. It seems like you're misinterpreting this as an issue with Pixels. GrapheneOS adds the Sensors permission because they leak crude forms of audio, location, etc.
1
I think you are mixing up questions : I never spoke about custom hardware, and I didn't stated it was an issue for grapheneos project. Just asked a genuine question (that may look naive for an infosec expert) about the reality behind the wording "microphone permission".
1
and thanks to your detailed answer, I know now it's a 'misleading' wording, at least for every android based OS.
1
The microphone permission controls access to the microphones. It's only ever possible to permit it for an app in the foreground.
It's not specific to Android but rather is also how this is designed in iOS, web browsers and elsewhere. Motion sensors, etc. are done separately.
1
The issue with motion sensors and various other sensors is that they essentially act as a form of side channel. They leak crude information about location, sound and other aspects of the environment through what they provide. Android and iOS throttle polling to mitigate this.
If the device is compromised, then the OS enforced throttling for polling isn't relevant. For the threat model of a hardware kill switch, nothing enforced by the OS is relevant.
A mic kill switch alone doesn't work. High freq polling of motion sensors makes them decent mics.
1
An audio recording kill switch really has to disable various other sensors too. A fully functional location kill switch would have to disable all of that (audio recording), audio playback (look up ultrasonic location tracking), the various radios and of course GPS.
1
Show replies