elementary
Display Permissions Requested by Flatpak Apps
It would be good to provide a list of permissions requested by Flatpak Apps, now that that support is present. There's almost certainly some design needed to ensure this looks good and works well from a UI and UX standpoint. But providing this information is necessary for users to know what a specific application has access to and whether they're okay with the security implications of that app.
I believe this functionality already exists in GNOME Software and is provided by libflatpak, so we should be able to get that information for any given flatpakref fairly easily.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
A really difficult challenge here is that just listing a bunch of permissions does not really educate the user what exactly an app can do. Just listing “access to X server,” for example really implies a ton of permissions like “read clipboard data, “see the contents of any window,” “track what apps you use,” etc. For curated apps in AppCenter that's not a concern because we vet each and every app and update. But a random app downloaded from a random repo could pose a much larger risk.
I wonder how useful this is when we have run time permissions with portals. It seems like install time permissions were moved away from on Android and I’m not sure they’re very effective on the web. Given a big list, users probably just click “Approve”
Even if the average person is likely to trust what they're given access to without question, there is the vocal technical crowd that appreciates being prompted about potential security concerns, especially for software from third party sources.
@cassidyjames That's a really good point. Perhaps displaying something like a tag for each permission requested in the manifest, with a tooltip/popover (on click) that explains some of the implications each of those bring.
Even within curated Apps though, there's something to be said for letting the user know about mic/camera, location, internet, etc access, which may be totally okay for some people and some apps, but other people might prefer not to use --for example-- text editors that require net access.
@danrabbit Also a good point. I think popping up a dialog on install is likely not the right way to do it, and having prompts per-permission with portals is definitely better. This might be more for cases where a prompt doesn't make sense/isn't supported by portals.
Even on Android, it's possible to get a list of permissions from the Play Store prior/subsequent to installing an app. There's a full list as well as some helper text explaining where a user can go to disable access to these permissions on their device.
Perhaps displaying something like a tag for each permission requested in the manifest, with a tooltip/popover (on click) that explains some of the implications each of those bring.
Just wanted to mention that its really hard to get the implications right. Some permissions can be subtle in how they allow total sandbox escapes. Since elementary is still using x11 I would consider that to apply to literally every application too.
I'd also love this for being able to know before install time whether an app is going to be able to mess with my system or not by default. Like described on http://flatkill.org/2020/ there are some permission grants for Flatpak'ed apps which practically disable the sandbox.
In those cases it would be nice to know before installing the app - so I can make an educated decision if I really trust the app authors.
@marbetschar Currently, the policy is that unsandboxed apps (those that require --filesystem=home or above permissions) are not allowed on the AppCenter (see https://github.com/elementary/appcenter-reviews/pull/225).
I am going to go through and see what the existing AppCenter apps do for a post I’m writing on the subject.
As for the policy regarding this, I would recommend allowing apps that have a legitimate reason to have home and above filesystem permissions (like my developer tool, linked above) but to mark them as unsandboxed.
The worst possible scenario would be to allow such app but to mark them as sandboxed or to have people believe they are sandboxed. (And, again, as I mentioned in the conversation in the link-to pull request, in apps with home and above permissions the actual security comes from the code review and any automated tests that may or may not be run during the review.)
(This goes for free/open source apps, of course, and following a source review.)
Since there's no clear scope and this issue could just be open forever, I'm opening a discussion here: https://github.com/elementary/appcenter/discussions/2045
And I have a number of branches out right now that should more or less close the scope of "Warn if apps can break out of the sandbox or access the system in catastrophic ways"