search

blueman-project / blueman

Blueman is a GTK+ Bluetooth Manager
GNU General Public License v3.0
1.27k stars 193 forks source link

Always allow / deny specific services #1770

Open cschramm opened 2 years ago

cschramm commented 2 years ago

From Debian #1014185:

I have connected a bluetooth headset to my system, to use as an output device. It works, but I keep getting "Authorization request" popup windows from "Bluetooth Authentication" for "Service: Phonebook Access (PBAP) - PSE". My device doesn't need phonebook access, so I keep clicking "Deny," but while that dismisses the popup, it keeps coming back every minutes or two. This is really annoying - it interrupts my workflow, and the popup steals focus suddenly from whatever I'm doing. There is an "Always accept" button, so I suggest the addition of an "Always deny" button.

The user seems to have a problem with his notification-daemon, thus the mention of a popup. I'm also wondering what kind of headset that is / what it would actually do with phonebook access, but I guess an "Always deny" button for a certain service is a proper addition. At the same time, this uncovers the misleading nature of the "Always accept" button: What it does is that it marks the whole device as trusted while the user might expect it to only apply to the specific service.

infirit commented 2 years ago

I think it's good to have a broader discussion on how we handle connecting, pairing and trust. For example, bluez will initiate pairing whenever it has to so there is no real point having the pair option in our menu.

More related to this issue, we have auto connect profiles and it does not make sense asking to trust one of those profiles. So we may as well set all devices as trusted when a user connects. Haven't checked if phonebook profile is one of the auto connectable ones but it wouldn't surprise me if it was.

cschramm commented 2 years ago

Phonebook is not auto-connect.

Dropping pairing is an interesting idea. Not sure if it works out, e.g. may there be (legacy) devices that do not expose services as long as they are not paired? :thinking: The generic connect might make BlueZ pair them anyway, but as of now we would not even provide it.

Trusting auto-connect services once the user actively connects to them makes some sense, but is based on trust on service level that blueman would have to maintain as BlueZ does not. I'm not 100 % sure if a user would always want to allow a device to connect profiles that he once connected to, though.