After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 720274 - Store state about enabled BlueZ persona stores
Store state about enabled BlueZ persona stores
Status: RESOLVED FIXED
Product: folks
Classification: Platform
Component: BlueZ backend
git master
Other Linux
: High major
: Unset
Assigned To: folks-maint
folks-maint
Depends on:
Blocks:
 
 
Reported: 2013-12-11 16:32 UTC by Allan Day
Modified: 2017-04-09 20:20 UTC
See Also:
GNOME target: ---
GNOME version: 3.11/3.12


Attachments
bluez: Save/Restore list of enabled BlueZ persona stores (7.05 KB, patch)
2016-10-18 19:42 UTC, Philip Withnall
committed Details | Review

Description Allan Day 2013-12-11 16:32:37 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?".
Comment 1 Bastien Nocera 2013-12-11 16:47:10 UTC
(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.
Comment 2 Philip Withnall 2013-12-14 22:55:05 UTC
(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.
Comment 3 Philip Withnall 2013-12-20 14:59:25 UTC
(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?
Comment 4 Philip Withnall 2013-12-20 17:12:10 UTC
Just pushed an interim fix which will effectively disable the BlueZ backend unless programmatically requested.
Comment 5 Philip Withnall 2014-06-24 07:25:16 UTC
(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?
Comment 6 Bastien Nocera 2014-06-24 14:57:40 UTC
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.
Comment 7 Philip Withnall 2014-06-25 16:40:33 UTC
(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?
Comment 8 Bastien Nocera 2014-06-26 12:14:13 UTC
(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)
Comment 9 Philip Withnall 2014-06-26 14:29:08 UTC
(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.
Comment 10 Bastien Nocera 2014-06-27 08:42:18 UTC
We'll see afterwards if the UI changes need to happen in gnome-contacts, or somewhere in the control-center for example.
Comment 11 Allan Day 2014-11-17 19:15:38 UTC
Adding this bug to the target list for GNOME 3.16. See desktop-devel-list for more discussion about this.
Comment 12 André Klapper 2015-02-22 21:01:54 UTC
(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?
Comment 13 Philip Withnall 2015-02-22 21:29:31 UTC
(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?).
Comment 14 Matthias Clasen 2015-03-02 16:25:27 UTC
dropping target
Comment 15 Allan Day 2015-11-04 10:51:40 UTC
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.
Comment 16 Philip Withnall 2016-10-18 19:42:19 UTC
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.
Comment 17 Philip Withnall 2016-10-18 19:43:19 UTC
(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.
Comment 18 Philip Withnall 2017-01-22 11:38:36 UTC
Anyone fancy reviewing this?
Comment 19 Philip Withnall 2017-04-09 20:20:27 UTC
I got bored of waiting.

Attachment 337968 [details] pushed as 780d64a - bluez: Save/Restore list of enabled BlueZ persona stores