Disabling "Find my device" on OS level or firmware level?

ghg129

Hi @GrapheneOS, i was glad to read, that FMD won't be supported (https://discuss.grapheneos.org/d/11520-android-find-my-device-when-powered-off/12).
But it now seems supported optionally, which can be seen on the screenshot posted here: https://github.com/GrapheneOS/os-issue-tracker/issues/4079.

I can't find any detailed information about FMD's hardware/firmware implementation on Pixel series 8 and up. I want to ask you to share some insight on if and how grapheneos will be actually able to circumvent the activation of bluetooth by firmware in general and when the device is switched off and "out of battery"(with the power reserve for FMD available)?
Are you also able to inspect and if necessary alter the device firmware accordingly?

Sorry for the lack of the technical background, but it is really important to get some info about that topic, since the main focus of most of users on using grapheneos (and therefor buying a recent Pixel device) is supposedly the full control over privacy and security.
And i want to finally upgrade to a recent device, coming from my good old Pixel 4a.. And Black Friday is around the corner.. ;)
Thanks in advance!

de0u

ghg129 The posts in issue #4079 appear to be about a device running GrapheneOS scanning for nearby beacon devices, which is in a sense the opposite of whether the GrapheneOS device itself can be located while it's on. In turn that is separate from whether the GrapheneOS device can be located while it's off. Scanning is the opposite of responding to a scan.

To my eyes, the traffic in that issue, about scanning, in no way undermines the previous project statement that GrapheneOS will not be configuring the Bluetooth hardware to respond to scans while the remainder of the device is off.

ghg129

Thanks for your clarification.
I was to quick with my assumption, it was not my intention to claim FMD would now be optionally supported, just went over that screenshot too quick.

But since there is no further detailed information to be found, other than FMD won't be supported, the basic question remains, how a hardware-firmware-feature will be reliably circumvented/disabled by GOS? As far as i understood, even with the device switched off or "out of power" the bluetooth module will be supported with a power reserve for hours.
I wouldn't be surprised, if the bluetooth module would at least act as a relay for the FMD network, without permission asked...

Some more information on this would be much appreciated.
I want to buy a Pixel 8a as my next GOS device next week, but only with the proof, that FMD can reliably disabled at all device states and user profiles.

Please developers share some insight on this! Thanks

Carlos-Anso

ghg129
In your opening post you linked to a thread where we explained it wont work with the device powered off.

Its possible to get FMD to work with the device on by granting the necessary permissions to various Google apps. You can see people explaining what they needed to do to get it to work here- https://discuss.grapheneos.org/d/14843-google-timeline-location-data-now-saved-on-device-should-we-use-it-and-how

ghg129

Thanks for the link and the clarification.
So it will actually work with the proper permission configuration and Play Services etc.. For people who want to actally go that way wit GOS.

You are right i was referencing to a post where it was stated by @GrapheneOS that FMD won't won't be supported, in 2 short sentences.

Knowing that every other topic of way less importance to the security and privacy of a GOS device, is addressed in detail and depth with long and precise comments, it is kind of discouraging to just read 2 short sentences about this tremendously important security topic.

@GrapheneOS please share some more in depth information about how a hardware/firmware based device feature with dedicated power source when switched off (GOS not booted) can be reliably disabled by GOS?
And is there even a way to check, if the device doesn't at least act as a relay without asking permission (when switched off).

I know that Memory tagging is a big plus on the newer 8 and up Pixels, but not knowing for sure that FMD/device-switched-off-mode-bluetooth can reliably be disabled and having proof for that, what would be the worse flaw?

Thanks in advance and don't interpret it as criticism, it's not meant that way. I'm a GOS head from day one and would live to continue to feel fully safe with it.

de0u

ghg129 Please share some more in depth information about how a hardware/firmware based device feature with dedicated power source when switched off (GOS not booted) can be reliably disabled by GOS?

Are you sure it's possible for this request to be met? Here's what I mean.

Let's say the official account gave a much longer answer, something like "The code to enable BLE relay operation while the processor is off exists in xxx.c in the stock OS and we don't ship that file". Would that suffice? Or would the next question be "How can I be sure that GrapheneOS leaving that one file out disables standby BLE relay? How can I be sure that there isn't code somewhere else that turns it on also?".
Let's say that somehow or other the official GrapheneOS account provided a very long detailed statement that seemed convincing. What about the next release of GrapheneOS? After all, the next release of GrapheneOS would typically include a lot of code changes from Google. Maybe somewhere buried in all of that code there would be something that could secretively enable standby BLE relay!

ghg129 And is there even a way to check, if the device doesn't at least act as a relay without asking permission (when switched off).

The good news is that there is a way to check, but there is bad news also. The good news is that if you take your phone to a qualified RF engineer with the right equipment, that person can point a spectrum analyzer at your phone while it's off and measure whether or not it is running a Bluetooth transceiver. If not detecting a signal for 10 minutes isn't enough, you could watch the phone for an hour, or a day, or a week. The bad news is that (presumably) it would be necessary to repeat the experiment each time there is a new release of GrapheneOS. And the other bad news is that so far there is no sign that any of the GrapheneOS developers has access to the right kind of RF equipment.

It may be the case that the brief answer that seems too brief is actually exactly the right length -- if the situation is that longer answers from the GrapheneOS developers would remain unconvincing, and if the actually-convincing answer would come from somebody with a bunch of RF equipment and enough time to monitor a powered-off phone for a day.