• DevelopmentSolved

  • Bluetooth shares contacts and calls history despite being turned off by default.

@akc3n and @matchboxbananasynergy Can I please ask for a second opinion on this? Sorry to tag you but it may not be reproducible after tomorrow if you update. Try a car with pairing profiles deleted on both your phone and the car before re-pairing.

In disclosing this issue I followed the SECURITY.MD guidelines from the GOS issue tracker, which suggested filing a Github issue if it does not need to remain private. I filed issue 4396 but Daniel deleted it and edited my comment above to remove its hyperlink to the issue. Many thanks.

@words Is "Turn off Bluetooth automatically" option enabled in Settings > Security & privacy > Exploit protection? If yes, what is it set to?

    @words Do you have multiple users on your device? If yes, did you initiate pairing from the main (Owner) user?

      muhomorr

      If it helps, when my contact details leaked it was from the owner profile, with no other profiles on the device. I have Bluetooth set to turn off automatically after 4 hours. I initiated pairing from the car after opening my phonecs Bluetooth settings so it was discoverable, with a fresh rental car that had never paired with my phone before.

          tw-hx Did you observe this issue before the current OS release? The issue got worse in the current OS release.

            Sorry, I can't state definitively it has occurred with a prior GOS release, only the current one for me.

            Do you think PR#299 affected this, and the above patch will improve at least that issue for the current release?

            muhomorr It was always on and i set it to 2 minutes.

            muhomorr I only have the Owner profile.

            I know this issue could've got more developer eyes if i were to report it on the GitHub issue tracker, but i can't do this yet since GitHub anti-spam measures prevent me from creating a proper anonymous profile. I'd like Graphene developers to pay more attention to their own forums. I've reported more issues here and would like to get a reply back.

                @tw-hx PR 299 made the issue worse. It's not clear whether the new patch will fully resolve it.

                  @words Did you initiate pairing from the Settings app or did you use some other app to do it?

                    muhomorr

                    Thanks for confirming. It looks like PR#299 affected both createView() and createPinEntryView() in BluetoothPairingDialogFragment.java with a bug as outlined in my earlier post, desynchronising the UI and the underlying permission.

                      muhomorr I can't, it's deleted now. It simply shows that, after connecting to a new device, in device details, Allow access to contacts and call history is turned on despite the default choice being off.

                      muhomorr The settings app, and not the bluetooth tile.

                      To be clear, this bug seems to be occurring only with a specific Bluetooth speaker i own.

                          muhomorr It doesn't. It only shows a "Pair with <devicename>" dialog when pairing with a new device.

                            @words Did Settings app ever show a "Pairing request" notification before?

                            I'm asking because the pairing dialog worked differently when you've reported this issue on October 5th.

                              muhomorr I believe i didn't see the notification, but i'll redo the procedure when i'll get near the said speaker/

                                Here are our changes for today's release related to this:

                                Settings: revert our attempt at disabling Bluetooth contact sharing by default for hands-free calling devices in our <a href="#2024111700">2024111700</a> release because it didn't address an upstream Android security bug and caused it to occur when invoked from the foreground (i.e. directly by a user in the Settings app) instead of only the background (i.e. Settings being opened by a pairing request)
Settings: fix an upstream Android security bug causing Bluetooth contact sharing to be enabled for hands-free calling devices even though the dialog shows it will be disabled, which only previously occurred when invoked from the background but began occurring in the foreground too after out previous change which attempted to fix this issue
Settings: always disable Bluetooth contact sharing by default instead of enabling it by default for pairing requests made by the user in the foreground where the user can choose to disable it

                                We did not create the upstream security bug. We failed to properly fix it and changing the default value caused the upstream security bug to impact another case which it didn't previously impact. This was introduced in our 2024111700 release which didn't go beyond our Alpha channel so the 2024111800 release is what caused this upstream security bug to impact an additional case for the Beta and Alpha channels.

                                We appreciate @tw-hx reporting the issue to us but there was no need to so much hostility towards us and refusing to listen to us about the cause of the issue being an upstream bug which was already present and impacting people before our change which was intended to both switch to a better default and fix the upstream security bug. A contributor submitted the fix and we reviewed and tested it. It appeared to work properly, but it didn't address the upstream security bug which was impacting @words here. It also caused it to trigger when invoked from the foreground, not only the background. It's unfortunate that we made a serious upstream issue worse rather than better by causing it to occur for both ways of doing pairing (within Settings app and from outside it) instead of only one way. It appeared to work correctly based on our testing and user feedback about it. We did not fully understand the upstream bug. That's how things are sometimes.

                                The issue initially encounted by @words could be reported upstream to Android because it does occur for the stock OS and AOSP. @tw-hx is correct that we made the problem worse by causing it to impact another UX flow but is NOT correct that we introduced the problem of Bluetooth contact sharing being granted with the dialog showing it won't be granted. That is an existing upstream bug which @words encountered and was part of what we wanted to fix with the change. We thought the change we accepted fixed the issue, but it didn't, and it made it occur in the other UX flow too.

                                We did not introduce the bug but disabling contacts sharing by default caused it to happen in a new case. The upstream code was incorrectly written. The upstream bug was already sharing contacts access with hands-free Bluetooth devices with no way for users to avoid it (even toggling it on and off) when triggering pairing outside Settings or in edge cases. Our change to the default extended this to doing it within Settings too, making it worse. However, the issue is now properly understood and the root cause is fixed for today's release.

                                We made an announcement about the issue explaining the existing upstream bug and how us disabling contact sharing by default triggered it in the other case (foreground, i.e. doing it from Settings without any edge case like a switch away from it) in addition to the existing case it happens with the upstream code alone (background, i.e. pairing without Settings open):

                                https://grapheneos.social/@GrapheneOS/113557179802653687
                                https://bsky.app/profile/did:plc:kym5w7pcv4v7xbz7lvbj24na/post/3lbxkuk7yxc2e
                                https://x.com/GrapheneOS/status/1861891708071420323

                                Probably the worst regression we've caused.