Introduce new users to snap permissions

I think Snaps are promoted like “one-click-and-works” packages, but in many cases it isn’t like so. Android provides on-demand popups when an app requires additional permissions. In Ubuntu all you have is a dropdown in Ubuntu Software. If you’re using Snapcraft then it’s none. And most apps even don’t tell that they may need some plugs and what plugs serve what cause (some, like Remmina, shows a simple message on start). This isn’t user-friendly and creates rage.

I’d like to see a more unified approach: why do you need a NetworkManager, or “if you enable this you can do that”, a link to permissions in the app menu (the dropdown right to the Activities), a tutorials about snap permissions and comparison to Android on first boot, etc.

Because of this every day we see these posts and half of “My beautiful Ubuntu desktop” posts on Reddit shows 0 snaps in neofetch.

1 Like

I think the classic snapd interfaces are born from its roots, i.e. IOT, server apps and the like. They are not really designed to be interactive in the Android/iOS-sense.

However, with the adoption and refinement of its xdg-desktop-portal integration (and also the improvements to the portal itself), a lot of stuff will just start working with the proper user prompting, as you would expect.

To properly support this, snapd and also the apps must be adapted (e.g. Qt’s and GTK’s file dialogs using the desktop portal).

1 Like

There is also some upcoming work to enable prompting, which will dynamically ask if a given application should be allowed to perform a specific action. This will be implemented at the AppArmor LSM / kernel level, and will be exposed via snapd very similar to how xdg-desktop-portal does this. In this world you would have something just like how Android/iOS works in that when an application tries to use a resource, snapd will prompt the user to allow access to this. We need to be careful though to not allow applications to spam this prompting system and also to make it clear to the user what the access the application tried to use actually means so folks don’t get accustomed to just always clicking “yes allow”, etc.

I should note that while this is on multiple teams roadmaps, it will be a large amount of work so it could be a while before this is in a deployable state and it will only work with new enough AppArmor and kernels.