Can someone explain where the code for this will be located (aosp, gsf)? How can I make sure that it will never ever be activated? What Graphene’s response? etc
it looks like its going to be a hardware feature. if the main CPU is off, it implies the radio circuitry and its CPU (the BBM) are still powered. give google this at least, the special new Bluetooth API will be accessible to whatever OS is alive and awake to send commands (even if I don’t trust that “off” means “off”). the fact that its using encryption (that’s too complicated to be made out of Integrated Circut logic) means its likely another software feature added to the BBM co-processor (it handles all radio tasks on the phone). this all but confirms the BBM (at least going forward) will still get power, be awake and have access to the (transmit (TX) and reseave (RX) functions of the) radios even when everything else is properly off.
EDIT: or it could be an abuse of a generic BLE beacon mechanism that’s “just there for whatever the consumer would need it for”.
but if they are doing proprietary encryption like they claim, that’s not really possible without updating the BBM’s software to add another feature.
Probably about as effective as keeping an air tag or tile tracker in one. That is, if the problem behavior isn’t correctly disabled by or even encouraged the OS.
damn that really sucks… sounds like it may just be an OS/firmware change then that activates the radio controller?
either way this is is exactly why we need a new community built piece of hardware. we cannot keep being slaves to Google’s whims just to use Graphene. i know there are other OS’s but either way it’s still Big Tech dependence.
Can someone explain where the code for this will be located (aosp, gsf)? How can I make sure that it will never ever be activated? What Graphene’s response? etc
They said they won’t support it https://discuss.grapheneos.org/d/11520-android-find-my-device-when-powered-off/2
it looks like its going to be a hardware feature. if the main CPU is off, it implies the radio circuitry and its CPU (the BBM) are still powered. give google this at least, the special new Bluetooth API will be accessible to whatever OS is alive and awake to send commands (even if I don’t trust that “off” means “off”). the fact that its using encryption (that’s too complicated to be made out of Integrated Circut logic) means its likely another software feature added to the BBM co-processor (it handles all radio tasks on the phone). this all but confirms the BBM (at least going forward) will still get power, be awake and have access to the (transmit (TX) and reseave (RX) functions of the) radios even when everything else is properly off.
EDIT: or it could be an abuse of a generic BLE beacon mechanism that’s “just there for whatever the consumer would need it for”. but if they are doing proprietary encryption like they claim, that’s not really possible without updating the BBM’s software to add another feature.
How effective do you believe that a Faraday cage would be against this mechanism?
Probably about as effective as keeping an air tag or tile tracker in one. That is, if the problem behavior isn’t correctly disabled by or even encouraged the OS.
damn that really sucks… sounds like it may just be an OS/firmware change then that activates the radio controller?
either way this is is exactly why we need a new community built piece of hardware. we cannot keep being slaves to Google’s whims just to use Graphene. i know there are other OS’s but either way it’s still Big Tech dependence.