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

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

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.

@GrapheneOS Probably the worst regression we've caused.

Be kind to yourself @GrapheneOS Your software makes this mobile world a safer and more private place and is light-years ahead of anything else out there, IMHO. But you're still human beings and nobody can be flawless 100% of the time. As we all remember what we are thankful for this week, I would like to say I am very thankful for this project.

DeletedUser88 Yes, it has no impact on that. The upstream bug was force enabling contact sharing for the initial pairing with hands-free Bluetooth devices. Without our change, this impacted pairing via quick tile, notification, etc. where Settings wasn't in the foreground and force enabled it regardless of what the toggle showed. After our change disabling contact sharing by default which removed one of the special cases for hands-free calling getting it enabled with the state as UNKNOWN, we thought it would fix the issue in this thread. It did not fix the issue. It also meant that for the case of doing it with the Settings app in the foreground, since it was disabled by default, the buggy upstream code force enabling it under the hood would no longer match it showing the toggle as enabled by default for those devices. With it enabled by default, there was an opportunity to see it was going to be enabled and disable it. With it disabled by default, the upstream code force enabling it regardless of the toggle would be overridden by a user disabling it there. The upstream bug did still force grant it without our change. The stock OS will still have that bug.

Thanks @muhomorr for your patches addressing this. I agree the desynchronisation between getContactSharingState() and setContactSharingState() is the underlying upstream issue and your patches hopefully resolve this.

@GrapheneOS thanks for acknowledging and explaining the regression caused by PR#299 affecting builds 2024111700 and 2024111800. When you deleted my initial bug report I was worried that this was going to be swept under the carpet as an upstream bug, so congratulations and thanks for posting your notices on GrapheneOS's social accounts. Here's looking forward to improved Bluetooth security.

tw-hx funny, offtopic and not so nerdy observation, you don't need many things (and certainly not something called Bluetooth} to live a fulfilling and happy life. I know, syntax error.

We tried to improve the wording of the release notes compared to what was posted above so people can have a hope of understanding it:

https://grapheneos.org/releases#2024112700

@DeletedUser69 This is not an app permission. It controls how the Bluetooth component deals with pairing with devices and whether it shares contacts. There was an issue with the upstream code accidentally force enabling it hands-free calling devices instead of only enabling it by default for them. This caused it to always get enabled for pairing started from outside the Settings app. Our change disabling contact sharing with Bluetooth devices by default meant that the checkbox was off by default in the Settings app pairing UI which meant the upstream bug force enabling it prior to that would remain enabled instead of users having an opportunity to override it. It was never working as intended anywhere, the upstream bug was just masked within the Settings app pairing interface before we disabled it by default. Turning it off by default meant someone would have to do the unusual sequence of toggling it on and then off again to override the force enabling from the upstream bug. We didn't introduce the upstream bug and it already did impact pairing requests started outside the Settings app. That's what happened to @words and why they filed this issue in the first place. We couldn't replicate an issue and we revived someone's pull request disabling contact sharing by default (which they didn't do incorrectly) with the hope it would fix this based on removing a special case. It didn't fix it and unusually setting a more private default caused the upstream security bug to have an impact in the Settings app too. They were trying to fix what happened for background requests based on the pull request discussion, it just didn't achieve that and caused another issue.

GrapheneOS

Would it be possible to add a notice to the release notes that users should check the permissions of all new Bluetooth devices paired with build 2024111800? For me, my contacts wound up in a rental car; users may have a limited time window to check devices like that.