Interface auto-connect request for the telegram-desktop snap (u2f-devices, bluez)

store-requests privileged-interfaces
1 
name: telegram-desktop
description: official telegram messaging app
snapcraft: https://github.com/telegramdesktop/tdesktop/blob/dev/snap/snapcraft.yaml
upstream: https://github.com/telegramdesktop/tdesktop
upstream-relation: maintainer
plugs:
  u2f-devices:
    request-type: auto-connection
    reasoning: support for USB passkey log in
  bluez:
    request-type: auto-connection
    reasoning: support for Bluetooth passkey log in
2

This request has been added to the queue for review by the @reviewers team.

3

Thanks @john-preston. Good to have hardware-key login in the official Telegram snap.

For u2f-devices: +1 for auto-connection. USB passkey/security-key login is exactly this interface’s purpose and its scope is inherently limited to known FIDO/U2F token IDs, so auto-connecting it is straightforward and consistent with how it’s granted elsewhere.

For bluez: The interface grants access to the BlueZ D-Bus API, which is general Bluetooth management (enumerate, pair, connect, communicate with devices), rather than a passkey-scoped capability. Two things:

  1. Can you confirm the BLE passkey login flow genuinely requires the full bluez interface? I want to make sure the feature actually needs Bluetooth-stack access rather than the USB path (which u2f-devices already covers), and that we’re not granting broad Bluetooth access under a narrow feature banner.
  2. Given most of the install base won’t use a BLE passkey, would manual connection for bluez be acceptable? u2f-devices auto-connects cleanly because its scope is narrow; bluez auto-connect grants Bluetooth access to every install for a feature few will exercise. Manual keeps the feature one snap connect away for users who want it without that broad default.

Will wait for your explanation, but for now u2f-devices is a +1 now as auto-connection

4

+1 from me of u2f-devices and will wait for the explanation for bluez

5

Hi, @john-preston is the main developer while I can explain Linux/Snap details.

It’s for caBLE v2. It scans devices to get the EID. You can see the used bluez APIs at tdesktop/Telegram/SourceFiles/webauthn/cable_scanner_linux.cpp at dev · telegramdesktop/tdesktop · GitHub or tdesktop/Telegram/SourceFiles/webauthn/org.bluez.xml at dev · telegramdesktop/tdesktop · GitHub if you just need a declarative list (+ org.freedesktop.DBus.ObjectManager.GetManagedObjects , org.freedesktop.DBus.ObjectManager.InterfacesAdded, org.freedesktop.DBus.Properties.{PropertiesChanged,GetAll} via glib abstractions). If there’s another interface that fits better, please tell.

I would say the other way around. Using the smartphone as the passkey is going to be the main use-case, the QR code is what the user sees when clicking on passkeys menu item when Bluetooth is accessible, USB passkey remains an alternate option accessible by a link under the QR code in that window. Given that the passkey feature is used instead of sending SMS and some countries block Telegram’s SMS, that could be the only way a lot of people can log in (SMS is the first factor in Telegram). Though if you still don’t think it deserves auto-connection, please tell how we can present the permission settings UI (ideally something like QDesktopServices::openUrl(“ms-settings:privacy-microphone”)) to instruct the user to enable it. Otherwise the user just won’t get how to enable it and the feature will remain completely inaccessible.

6

makes sense, +1 for auto-connection of both u2f-devices and bluez for telegram-desktop, on the basis that bluez is required for the caBLE BLE passkey flow which is a primary and in some cases sole login path.

7

+1 from me as well to grant auto-connection to both u2f-devices and bluez interfaces for telegram-desktop snap.

8

+1 also from me. +3 for, 0 against granting telegram-desktop auto-connection to both u2f-devices and bluez interfaces. The request can be fast-tracked. This is now live.