GNOME Bugzilla – Bug 720274
Store state about enabled BlueZ persona stores
Last modified: 2017-04-09 20:20:40 UTC
I recently paired my phone over bluetooth. Now, when I turn my laptop on, my phone pings and says "phone book access request". This is surprising and a bit disturbing. I didn't ask my laptop to access my phone, and it isn't clear what it is trying to (do I have a virus?) It isn't even clear that it is my laptop that is doing it, since the notification in my phone identifies the requester as "Broadcom bluetooth somethingorother". We should only ever access data on another device after getting explicit permission from the user. Otherwise the behaviour becomes surprising and scary. It makes us appear untrustworthy. One appropriate way to expose this behaviour would be through the Contacts app. The first time you open contacts after pairing a phone, it could ask "Do you want to import contacts from your phone?".
(In reply to comment #0) > It isn't > even clear that it is my laptop that is doing it, since the notification in my > phone identifies the requester as "Broadcom bluetooth somethingorother". That's usually a driver bug (I have the same problem on my laptop, the adapter loses its name after sleep/resume). Note that the phone might also have cached the name of your laptop in that state which would explain why: hciconfig hci0 name | grep Name shows something appropriate when the phone does not. > We should only ever access data on another device after getting explicit > permission from the user. Otherwise the behaviour becomes surprising and scary. > It makes us appear untrustworthy. It should definitely default to off and be requested by the user.
(In reply to comment #0) > We should only ever access data on another device after getting explicit > permission from the user. Otherwise the behaviour becomes surprising and scary. > It makes us appear untrustworthy. We are currently considering the explicit pairing between your phone and your laptop as permission, but on reflection this isn’t good enough, as you say. > One appropriate way to expose this behaviour would be through the Contacts app. > The first time you open contacts after pairing a phone, it could ask "Do you > want to import contacts from your phone?". Sounds like a reasonable approach. On the libfolks side, we’d need to implement set_persona_stores() in the BlueZ backend, store a persistent list of Bluetooth addresses of enabled devices somewhere, and only enable a persona store if the appropriate device is available, paired, supports PBAP, isn’t blocked, and is on the list of enabled devices.
(In reply to comment #2) > Sounds like a reasonable approach. On the libfolks side, we’d need to implement > set_persona_stores() in the BlueZ backend, store a persistent list of Bluetooth > addresses of enabled devices somewhere, and only enable a persona store if the > appropriate device is available, paired, supports PBAP, isn’t blocked, and is > on the list of enabled devices. On second thoughts, perhaps libfolks should always create a PersonaStore for each (paired, unblocked, PBAP-supporting) Bluetooth device, but should expose a method to explicitly set it up as a source of contacts (and to make this persistent). This would mean adding a new libfolks-bluez.so library which clients would have to consume. The difference would be between clients using BlueZ directly, and passing a Bluetooth device ID string to libfolks; and using libfolks-bluez.so for everything. If clients used BlueZ directly, they could get more information about the Bluetooth device, but would need to duplicate some functionality from folks (such as checking for PBAP support). For advanced cases, libfolks-bluez.so could allow clients access to the BlueZ D-Bus proxy objects (or their object paths, or something) so clients could use BlueZ directly if needed. libfolks-bluez.so could take care of the simple, common cases though. Bastien, what do you think?
Just pushed an interim fix which will effectively disable the BlueZ backend unless programmatically requested.
(In reply to comment #4) > Just pushed an interim fix which will effectively disable the BlueZ backend > unless programmatically requested. ⇒ Not a blocker any more. Bastien, do you have any thoughts about comment #3?
I'd rather have seen something that didn't require application changes, and add the UI to contacts, or somewhere in Settings to allow each device to be allowed or disallowed. But that would require folks to keep state, not sure whether you want that.
(In reply to comment #4) > Just pushed an interim fix which will effectively disable the BlueZ backend > unless programmatically requested. For posterity: https://git.gnome.org/browse/folks/commit/?id=521b2635b09cc4b84536efdd7e22a0771083c814 (In reply to comment #6) > I'd rather have seen something that didn't require application changes, and add > the UI to contacts, or somewhere in Settings to allow each device to be allowed > or disallowed. But that would require folks to keep state, not sure whether you > want that. I think it would make sense for folks to keep state about which Bluetooth devices to turn into PersonaStores, since the user is very likely to want the same devices to appear everywhere that contacts appear. For other cases, the software in question can call bluez_backend.set_persona_stores() manually to override. My question was more about where you think the Bluetooth code for enumerating devices (for the user to choose to enable/disable) should live: in libfolks-bluez.so (which doesn’t exist yet), or in gnome-contacts?
(In reply to comment #7) <snip> > My question was more about where you think the Bluetooth code for enumerating > devices (for the user to choose to enable/disable) should live: in > libfolks-bluez.so (which doesn’t exist yet), or in gnome-contacts? I'd start with putting it in Contacts, and if the amount of code is too big (say, another application using folks wants to have this feature) then split it off. Does that sound good? (I doubt there would be any additional deps on top of GDBus/GIO, which folks already uses, so it could even live in the main folks library)
(In reply to comment #8) > (In reply to comment #7) > <snip> > > My question was more about where you think the Bluetooth code for enumerating > > devices (for the user to choose to enable/disable) should live: in > > libfolks-bluez.so (which doesn’t exist yet), or in gnome-contacts? > > I'd start with putting it in Contacts, and if the amount of code is too big > (say, another application using folks wants to have this feature) then split it > off. Does that sound good? Sounds good to me. I can make the folks changes (to save state about which BlueZ devices are enabled for contacts), but I don’t know if I can find time to make the gnome-contacts changes.
We'll see afterwards if the UI changes need to happen in gnome-contacts, or somewhere in the control-center for example.
Adding this bug to the target list for GNOME 3.16. See desktop-devel-list for more discussion about this.
(In reply to Allan Day from comment #11) > Adding this bug to the target list for GNOME 3.16. See desktop-devel-list > for more discussion about this. Nothing has happened since then in this ticket. Is 3.16 still realistic or should the GNOME Target be removed?
(In reply to André Klapper from comment #12) > (In reply to Allan Day from comment #11) > > Adding this bug to the target list for GNOME 3.16. See desktop-devel-list > > for more discussion about this. > > Nothing has happened since then in this ticket. > Is 3.16 still realistic or should the GNOME Target be removed? Not at all realistic, sorry, I’ve had no time for this. Please remove the target (I don’t seem to be able to?).
dropping target
I recently upgraded to GNOME 3.18 / Fedora 23. This bug seems to have got worse than before - my phone is now regularly pinging with the phone book request, whenever my computer is on. There's no way to stop it other than unpair the phone. It's extremely annoying.
Created attachment 337968 [details] [review] bluez: Save/Restore list of enabled BlueZ persona stores This allows us to persistently enable or disable particular Bluetooth devices for providing contact data. The idea is that a UI (such as gnome-contacts) could use [enable|disable]_persona_store() to set the list of enabled devices, so that even if a device is paired and supports PBAP, it doesn’t persistently ask for permission to send contacts to your laptop when you don’t want it to.
(In reply to Philip Withnall from comment #16) > Created attachment 337968 [details] [review] [review] > bluez: Save/Restore list of enabled BlueZ persona stores > > This allows us to persistently enable or disable particular Bluetooth > devices for providing contact data. The idea is that a UI (such as > gnome-contacts) could use [enable|disable]_persona_store() to set the > list of enabled devices, so that even if a device is paired and supports > PBAP, it doesn’t persistently ask for permission to send contacts to > your laptop when you don’t want it to. Better late than never.
Anyone fancy reviewing this?
I got bored of waiting. Attachment 337968 [details] pushed as 780d64a - bluez: Save/Restore list of enabled BlueZ persona stores