Conversation

Replying to

and

There's tons of work that needs to be done: github.com/GrapheneOS/os_ github.com/GrapheneOS/Van github.com/GrapheneOS/Aud github.com/GrapheneOS/Att github.com/GrapheneOS/har github.com/GrapheneOS/Pdf Can't afford to lose a day per month making builds removing a disabled-by-default feature.

github.com

Issues · GrapheneOS/hardened_malloc

Hardened allocator designed for modern systems. It has integration into Android's Bionic libc and can be used externally with musl and glibc as a dynamic library for use on other Linux-base...

You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more

Replying to

and

So either leave Bluetooth enabled or don't authorize apps to use it unless you trust them with it. The concerns you are raising don't make sense to me and I don't understand why you want special treatment for Bluetooth. We aren't making builds for things toggles handle just fine.

You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more

Replying to

and

Doesn't make sense. You're saying you're worried about attacker with local code execution on the device that's succeeding escalating privileges to the point that they can bypass the permission model / sandbox and change settings. Why focus on Bluetooth over the 3 other radios?

You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more

Replying to

and

Contact tracing in other operating systems doesn't impact GrapheneOS even if GrapheneOS users make use of Bluetooth. GrapheneOS is never going to force contract tracing on people. If you want GrapheneOS to do something it has to make sense and have a real threat model.

Replying to

and

Does not make sense to be concerned about disabled Bluetooth support unless what you want is a hardware kill switch for all forms of powerful data exfiltration including all the radios and speakers. Even then, it has a very limited scope / threat model where it counters anything.

Replying to

and

The attacker's code will export data as soon as possible and a hardware kill switch for all powerful forms of data exfiltration can only delay it rather than preventing it. Very limited scope for that to be useful. Probably a better idea to just turn off the device in most cases.

You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more

Replying to

and

We would like to have our own custom hardware where we can do things like hardware kill switches truly achieving their purpose with actual threat models. As an example, an input recording switch that disables microphone, speakers, accelerometers, gyroscopes, compass and camera.

4:28 AM · Apr 23, 2020Twitter Web App

Replying to

and

Since all of those things other than the microphone can also record audio to some extent. The accelerometers / gyroscopes can capture more than enough to record speech since they provide high frequency sampling of vibrations i.e. audio recording. These things are pretty messy.