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.
If it’s hardware controlled, then the Graphene OS team would have to find a flaw in the hardware, or trust that when they tell the hardware to shut off, that it really does shut off, or find a way to verify that the hardware is really of. But even if they could tell the hardware to shut off, verify that it’s off, and then shut down, the hardware could turn back on after the software is off and the software would be none the wiser.
The only way 2 ways anybody can be relatively sure this feature is off are:
pulling the battery:
good luck with that with phones that don’t have removable batteries
hopefully there won’t be a small backup battery to power this specific circuit
physically disconnecting this circuit from other circuits:
that might mean saying goodbye to bluetooth functionality on the phone
The alternative is getting a linux phone with hardware that doesn’t have this feature.
I hate that they don’t support them after a while, those with a locked bootloader wont even get a chance.
It makes these phones junk from all the CVEs that are being found.
What old model would you recommend?
Is something like postmarketOS viable yet?
What phones are/will be effected?
Do existing phones planned for the program have the payload sitting there dormant or will the system updater (on googled android) need to download the payload?
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.
We could wait for the implementation from the GrapheneOS team ! I’m pretty sure that they would implement it in a way that would be safe for the user.
If it’s hardware controlled, then the Graphene OS team would have to find a flaw in the hardware, or trust that when they tell the hardware to shut off, that it really does shut off, or find a way to verify that the hardware is really of. But even if they could tell the hardware to shut off, verify that it’s off, and then shut down, the hardware could turn back on after the software is off and the software would be none the wiser.
The only way 2 ways anybody can be relatively sure this feature is off are:
The alternative is getting a linux phone with hardware that doesn’t have this feature.
Anti Commercial-AI license
Fuck, okay, Linux on my phone now, because corporations just spray shit on everything
I hope linux phones will become more of a thing as they aren’t there yet IMO. But of course you can always get a second hand phone… forgot that option
Anti Commercial-AI license
I hate that they don’t support them after a while, those with a locked bootloader wont even get a chance. It makes these phones junk from all the CVEs that are being found.