Restructure the permissions UI

[TheEvilSkeleton]

Related to https://github.com/tchx84/Flatseal/issues/165; since the permissions UI is really cluttered, my proposition is to make each section drop down.

Here's an example (in GNOME Settings):

[Arxcis]

An alternative to dropdown - also found in GNOME settings - is to to have sub-menus in the left menu

Sketch of how it could look in Flatseal

[Arxcis]

Twitter settings is another interesting alternative - Recomend checking it out for inspiration @ https://twitter.com/settings/account

[TheEvilSkeleton]

I personally prefer https://github.com/tchx84/Flatseal/issues/166#issuecomment-726403686.

[ssokolow]

For me, the biggest single usability improvement would be to turn the "Other files" fields into combo-boxes where the drop-downs contain common choices like xdg-documents:rw... or perhaps an editable combo box containing all the valid shorthands like xdg-documents and a dropdown box or popup-menu button with fixed options for selecting ro, rw, or create.

I'm used to quickly scrolling through things in Flatseal to narrow the permissions after installing an application, but it's both a slow-down and counter to Flatseal's goal of making overrides easier and more discoverable if you have to know the syntax and available options for that.

[stpnwf]

Unsure if this is the path Flatseal is planning to go, but I have a few suggestions, having the not so savvy end user in mind:

I would suggest that an Info icon be added next to every entry, offering a concise and user friendly explanation about what that permission/category does. Written in an ELI5 way so that the uninformed can get an idea of the consequences (what to expect) of enabling/disabling a permission.

Breaking down that specialized language so that it is more accessible to the end user, is in my opinion a non intrusive approach that has the potential to educate Flatseal users, while mitigating user error.

e.g: It might be relevant to the end user to know what permissions like "Inter-process communications" and "All system files" do so that they can better asses whether enabling or disabling it is the right call, will put their machine at risk or "break" the application.

---

Also, I think an option to organize the Sidebar by permissions as well, rather than by application can be simpler and more accessible to new users. Similarly to how macOs does it:

Maybe a toggle can be added to switch between the "Simplified view" and the current one? Therefore serving both savvy and non savvy folks.

[ssokolow]

Also, I think an option to organize the Sidebar by permissions as well, rather than by application can be simpler and more accessible to new users. Similarly to how macOs does it:

Huh. I can see the use for things like Camera and Microphone, but, on the whole, macOS's decision to make it what appears to be the only choice confuses me.

Going by permission rather than by application seems like the one you'd need less often... especially when "Full Disk Access" and "Files And Folders" are separate.

The current design is good for workflows like "Install application, then get an overview of or customize its permissions" while the macOS workflow seems more suited to "I feel like I'm being watched. Let's double-check what can see thing X."

Heck, all of the Android permissions inspectors I've seen have offered "by application" and, if it wasn't the only choice, made it the default one.

[stpnwf]

Fair point. I also included that example because (i think), most users don't know what all those permissions in Flatseal do, and Apple does a good job in simplifying them. I do think they over simplify though, but a sweet spot could be somewhere in between. Hence my proposition to add an info button.

[ssokolow]

No argument there. Definitely at least some info buttons.

I also wish that the underlying system would do a better job of handling the D-Bus permissions. (As a developer, how am I supposed to know which well-known names I need to grant to satisfy something like Qt's predefined integrations with various desktop features? There should be presets for them like with things like filesystem=xdg-pictures)

Just as a minor improvement, here are some ideas beyond my previous suggestion regarding the "Other files" fields:

Zeroth, All those "List of..." in the descriptions are unnecessary. It's visibly obvious that they're lists and it takes up space that could be the difference between a clearer explanation and avoiding word-wrap.

First, instead of structuring and labelling "Share", "Socket", "Device", and "Allow" based on their underlying implementations, leave that for the device=all subtitles to do, and just have a big "System Services" section. Users who care how it's achieved under the hood will read the subtitle.

Users who don't probably have no idea what a "subsystem" or "socket" is, and will probably have a "just assume it means something to someone" reaction to seeing them divided up that way.

To them, "Network" (or, more fittingly, "Full Network Access") and "GPU acceleration" are the same kind of thing and it doesn't make sense to group them the way they are.

It may make sense to still put them in separate groups, but that'd be more along the lines of grouping individual services into one group and unconstrained bus access like socket=session-bus into another.

...especially if Flatpak ever gains support for doing something like letting things like Discord talk to the public Internet, but not to private IP ranges on the local LAN where it could be exploited to bypass the gateway firewall and attack things like print servers which aren't up on their security updates or IoT devices that are no longer supported.

Second, the docs don't say that --filesystem's support for :ro and :rw is limited to a subset of valid arguments, so the Filesystem section should be redesigned to allow enabling/disabling writes on all entries, not just the eye-glazingly under-documented "Other fields" section.

Third, as I mentioned before, the "Other files" section shouldn't require a user to go dig through Flatpak's infamously sparse developer documentation to figure out what special values other than the xdg-pictures in the "e.g." line are supported.

Fourth, the "List of homedir-relative paths created in the sandbox" description of the "Persistent" section can be confusing, since applications can always create temporary paths within the section... they just don't get persisted under ~/.var

A better description would be something more along the lines of "Paths in the sandbox's home directory which should be preserved between sessions"... possibly with an info button that points to ~/.var/app/<APPID> for where they're actually stored.

Fifth, I'd make the "System Bus" and "Session Bus" sections into equivalents to "Other files" for my proposed "System Services" and "Session Services" sections.

Sixth, permissions like socket-session-bus or device=all should have a warning triangle next to them which, if hovered or clicked, displays a message like "This grants very broad permissions. If possible, prefer the more fine-grained subsets of it offered by other options."

Basically, I'd redesign the UI so it's structured around conceptual groupings that make sense to the user, rather than implementation details.