• DevelopmentSolved

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

Thanks Daniel for writing a patch to fix this issue.

I see that you have marked my Github issue as invalid, closed and deleted the report and its reproduction steps and explanation though 😔

Can we please have a new build of GrapheneOS with this fix included, and alert users in the changelog that all builds since PR#299 on Nov 11 have had their address books shared with newly paired Bluetooth hands free devices e.g. cars and therefore possibly uploaded to the device manufacturers, unless they used @words 's workaround of toggling the permission twice before pairing?

Many thanks again for improving GrapheneOS's Bluetooth settings over upstream.

Also, yes you are entirely correct that this may not explain @words 's initial issue in October, but did explain my issue in the last few days.

@tw-hx We did not introduce this issue or make it worse. The issue was present in the form you experienced it prior to our November 17th release. We did not cause contacts to be shared when the stock OS was not sharing them and the checkbox was unchecked for everyone despite it sharing them. The commit message was not properly updated for the current state of things when it was merged. They had kept an older message from the initial change. Read the discussion at https://github.com/GrapheneOS/platform_packages_apps_Settings/pull/299. The whole point of the change was trying to fix the upstream issue you're experiencing.

You do not understand what we changed or why, and if you refuse to listen and read the past discussion about it to realize that people experienced exactly what you did and the checkbox was already off by default before our change. Our change was intended to make the low-level default aligned with what the checkbox shows. We didn't introduce any part of the issue. We did not successfully fix it in every case because in some cases the value is set with the same exception before our change kicks in.

@tw-hx If you look at the thread above and the discussion on that pull request you'll see that we were trying to resolve what you're reporting and blaming on our change. You even blamed 8 weeks of the issue on us despite it being a very long term Android issue which we tried to fix on November 17th. We could not have introduced the issue in October and earlier with a change on November 17th. Other people had exactly the same issue you're describing before our change was made. We clearly did not fix the issue either completely or at all, but you're entirely wrong about what our change did and are wrongly blaming us for introducing it.

words We've made another attempt at fixing it and it should be resolved now. It will be included in the next release, which we can do tomorrow since we have some other important fixes too.

    @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.