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

Couldn't reproduce with other speakers either. But since confirmation for pairing and request for contact access appear in the same dialogue, there's the possibility to grant the access accidently.

@tw-hx You've misunderstood the situation. We weren't only trying to change the default but rather were also trying to fix the stock OS granting hands-free calling devices access to Contacts before a prompt was shown to the user or without the prompt being shown at all. It appears that it hasn't actually been fixed correctly but definitely it's not an issue introduced by GrapheneOS. The way you're approaching this is inappropriate and very counterproductive in terms of getting it fixed. If someone simply would have left a comment on the original issue we were trying to fix or opened a new issue we would have dealt with it already. This is an existing Android problem and us failing to fully fix it in every case doesn't mean we introduced a new vulnerability. Android was already sharing contacts with hands-free calling devices with no prompt and before it shown the prompt. It has been that way for ages. We were not only trying to fix the default setting.

@tw-hx You can see for yourself the thread was created on October 5th, most posts are from October and our change was made in the November 17th release:

https://grapheneos.org/releases#2024111700

This post from 2 days ago said the issue was still occurring:

https://discuss.grapheneos.org/d/16226-bluetooth-shares-contacts-and-calls-history-despite-being-turned-off-by-default/12

Our development team hadn't seen this report that the issue hadn't been successfully fixed. Now that we've seen it, we'll make further changes to try to address it. We clearly didn't introduce this issue as you repeatedly claimed on the issue tracker. Please look at the timeline here. How could be have introduced this issue in our November 17th release?

You say that it got no traction but we just recently put out a release with a fix that had been developed for it over several weeks. Your account of what's happening here and your claim that we introduced the problem is completely wrong.

Since our November 17th fix didn't work, we're making a further change to address the issue. The commit message does not properly explain what the commit is trying to do. Please see the discussion about it here:

https://github.com/GrapheneOS/platform_packages_apps_Settings/pull/299

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.

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

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?

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