Dear @reviewers, I would like to request the “hardware-observe” interface auto-connection for “telegram-desktop” snap according to the process for aliases, auto-connections and tracks so the application can get the information about the battery for battery saving.
The application has an option in Settings “Save Power on Low Battery” which disables power-consuming animations automatically in case the battery saving mode is on.
Thank you, John Preston.
The application has an option in Settings “Save Power on Low Battery” which disables power-consuming animations automatically in case the battery saving mode is on.
This doesn’t sound like something that is required (or even enabled by default), and could be something that the application could prompt for. Why do you feel this interface must be automatically connected for all your users instead of letting them opt in to allowing that level of access?
There’s no API to request a snap permission from the user AFAIK, so if this won’t be auto-connected then it’s just inaccessible to the user.
(the snapcraft.yml is mostly maintained by me)
The worst is there’s even no way to check whether a battery is present without this permission so we can’t know whether the menu item should be displayed at all. Currently it never sees a battery in snap (unless one is a power user and can enter a snap connect command in terminal) so there’s no such item at all for snap users.
For comparison: flatpak doesn’t require a permission for this, it works for any application. And I guess it’s justified that applications can read battery state.
True, I meant “you can prompt the user to connect this interface.” For example, you can run snapctl is-connected hardware-observe from within the snap and check the exit code (it’ll be 0 if connected, 1 is not).
Well, that’s not true, it just means it’s not connected automatically. The user can still connect it if they so choose.
But this won’t work for non-power users, so this is bad UX. It should either be a system dialog where the user can click “allow” or there should be a way for application to open some system settings page where the user can enable the permission. Prompting “enter this command for battery saving” would be frustrating for most users and if the user doesn’t have a battery, the item will disappear what will be even more frustrating. I also don’t know a way how to check that the permission is granted, currently the code just thinks there’s no battery.
AFAIK there’s only a way for power users (snap connect command). Non-power users can’t do that. Limiting battery saving to power users doesn’t sound good.
You won’t hear an argument from me. But automatically connecting interfaces isn’t really the solution either, is it? This interface isn’t automatically connected because it allows the reading of potentially sensitive information. This use-case doesn’t seem like enough to justify that to me. I’m -1 to automatically connecting hardware-observe to telegram.
Perhaps we need an interface that is limited to power information?
I think classifying users of snap connect as power users is a mistake. Snap users need to be able to use the confinement model as it exists today. Without the system you describe above (e.g. portal integration), snap connect is all we have.
Yeah, an interface limited to power information or a user-friendly way to ask the user (so one can just click-click-click like on Android and not enter various commands in terminal) to grant the permission should solve this.
Well, we deal with ordinary users everyday even via github issues (what is surprising). Most of them just install Telegram from Ubuntu Software and don’t even know how to enter a command in terminal. Battery saving is just inaccessible for them right now.
Yeah I hear you! I’m sorry, I can imagine this is frustrating. I think we can all agree that we want those kinds of snap users. But as soon as you start reasoning that the one interface with snap’s confinement model is too advanced, it’s easy to justify the disabling of security features. In reality, I’d say you’re just identifying a (perfectly valid) missing feature.
That all said, the software center exposes the interfaces via a UI. Does that help make this a little more user-friendly? Here’s the one for Telegram, for example:
If there was a way to open this dialog from the app (e.g. via some URL scheme like QDesktopServices::openUrl("snap://settings/" + qEnvironmentVariable("SNAP_NAME") + "/permissions");), that would be a perfect solution!
@ilya-fedin What you can do is, change the launcher of telegram to a shell script, which will prompt a zenity dialogue box, this dialogue box will ask user if he has a battery, if answer is yes, then ask him if he wants to auto connect or not/ simply auto connect directly by asking the sudo password from the user.
Though, I guess as the plug say it’s just to observe, will it be too much for a snap to get auto connected to this?
@soumyaDghosh honestly it sounds like it would be weird and annoying from user PoV (probably with no possibility for the user to reconsider the decision in a convenient manner). Does sudo work inside snap confinement? I thought it doesn’t. But I feel this is going to get security considerations from the users due to application processing their password (if this would be implemented then likely in the app itself, not via shell scripting with zenity).
From the user perspective, +1 from me. Security wise, -1. That said, Telegram is a highly popular tool, and a good user experience is mandatory. In this regard, it is the platform that needs a change, ergo a battery-specific interface. Since this is a verified publisher, plus we want the users to have a good snap experience, +1 from me.
John, can you file a bug/enhancement request for the interface development/creation?
For me, this one could really go either way. Arguments on both sides are hard to fault and I do think that we sometimes conflate auto-connection with allow-connection.
One of the factors that is playing into my mind is that I’d like to provide as secure a sandbox as possible for Telegram users so they can operate the application with as much confidence as possible; that generally means limiting the interfaces available to it (and particularly some of the information that might be learned from hardware-observe).
Before we get a battery/power-observe interface, would power-control be a suitable alternative? Yes it grants some abilities that are excess to Telegram’s needs, but it is a much reduced read- surface.
Would it be ok if I file it?
No, Telegram is using /sys/class/power_supply which doesn’t seem to be enumerated in the documentation of that interface.
Ok, well if power-control doesn’t work, I vote +1 for hardware-observe for now. A (currently non-existent) battery/power-observe should be considered as a replacement when available.
I was a bit hesitant to give +1 for hardware-observe due to the information it poses and given the use-case this snap doesn’t require all of this information, but since the power-control interface is not useful here, this snap is quite popular and the publisher is also verified, and it would be bad UX for users to allow hardware-observe interface by running commands, so I am in giving of +1 for auto-connect the requested interface.
thanks
