Gripe on "Potentially Unsafe" labeling

[droidmonkey]

Hello Flathub team! After reviewing the Flathub website today, I realized that a new feature is present showing permissions with "safety" ratings associated with them. This is very good, however the implementation is not good. Every single app on Flathub that I clicked on is labeled as "Potentially Unsafe". When everything is potentially unsafe, then nothing is potentially unsafe. I actually can't see how any app could possible by labeled as "Safe" unless it did almost nothing.

Please consider re-evaluating this display as it is very misleading to potential users.

Suggestions:

• Separate file system access from other permissions
• Don't mark an app as "Potentially Unsafe" as that is a very strong statement
• Use terms like "Unrestricted Access" and "Extra Permissions" instead
• Access to user devices should not be marked red, game controllers unsafe??
• Legacy windowing system - that really isn't a flatpak problem and our app works flawlessly on both X11 and Wayland so this is just untrue

[razzeee]

This is almost exactly what gnome-software implements, so it would make sense to talk with them.

• Separate file system access from other permissions

We explored that and it doesn't help, if fact I would argue it makes everything more complicated for users, harder to understand and less safe

Don't mark an app as "Potentially Unsafe" as that is a very strong statement

I do agree, but I don't think there is better wording for now. I also think the idea is to get apps to implement portals, so that they can become (almost) permission free.

Use terms like "Unrestricted Access" and "Extra Permissions" instead

Wayyy to technical IMO

Access to user devices should not be marked red, game controllers unsafe??

Devices are everything usb, so webcams and some yubikeys too for e.g. And it can be used for sandbox escape see https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1997

Controllers also should use --device=input instead, but not sure if all distros already have that / how good it works https://github.com/flatpak/flatpak/pull/5481

Legacy windowing system - that really isn't a flatpak problem and our app works flawlessly on both X11 and Wayland so this is just untrue

It's not about it working, it's about the security of the x apps. Your app is likely using XWayland to work on wayland, but I'm no expert when it comes to this.

[droidmonkey]

This is almost exactly what gnome-software implements, so it would make sense to talk with them

Yikes, I wouldn't copy them, nor do you have to. Own your own brand experience. Now that I am aware, I will also complain to them. At least you added "potentially" (thank you)!

I do agree, but I don't think there is better wording for now. I also think the idea is to get apps to implement portals, so that they can become (almost) permission free.

There is definitely better wording. You keep mentioning too technical for users. I dont disagree, but in the current state, it is far too vague for users. Was this tested with anyone outside this community?

After looking at the site again, I realized there is no sub-header over this section. At the very least, it should say "Permissions:" to introduce the reader to what lies in that box. Right now, nothing but "potentially unsafe", a red icon, and a list of some permissions is shown.

FWIW, some apps will never be fully on portals because of the nature of the app. Ours is one of them. Given that flatpak allows for modification of permissions on the client end (eg, with flatseal or via system settings), users can choose to disable certain parts they won't need.

[razzeee]

After looking at the site again, I realized there is no sub-header over this section. At the very least, it should say "Permissions:" to introduce the reader to what lies in that box. Right now, nothing but "potentially unsafe", a red icon, and a list of some permissions is shown.

I think that's the idea, we're omitting the permissions part, as it's nothing a normal user should know or ever care about. They would need to know what a permission is in the first place.

FWIW, some apps will never be fully on portals because of the nature of the app. Ours is one of them. Given that flatpak allows for modification of permissions on the client end (eg, with flatseal or via system settings), users can choose to disable certain parts they won't need.

I'm well aware, some of my apps, will probably never use portals. That's fine IMO, still we should try to migrate where possible.

[droidmonkey]

Certainly some users don't know what "permissions" are, but they definitely know what "unsafe" means, and it's entirely negative. Unfortunately, in my opinion, the way the information is presented right now makes it appear like the application itself is unsafe. It is certainly the most attention grabbing thing on the page besides the banner images.

Additionally, the way this information comes across (which was also discussed in this thread) may scare users away from Flatpak altogether. No such warnings exist when you install a natively-deployed application despite the total lack of any permissions. It creates a weird imbalance between wanting users to migrate to sandboxed applications while simultaneously declaring them "unsafe". Makes zero sense to me.

Google rightly moved almost all permissions notices behind a couple clicks, and instead promotes the data safety/handling aspects on the front page because that matters more.

I think we are also missing a chance to 'talk to the user' about why flatpak is more secure in general and how they can request permissions to be tightened up.

[razzeee]

Additionally, the way this information comes across (which was also discussed in this thread) may scare users away from Flatpak altogether. No such warnings exist when you install a natively-deployed application despite the total lack of any permissions. It creates a weird imbalance between wanting users to migrate to sandboxed applications while simultaneously declaring them "unsafe". Makes zero sense to me.

Agreed, but we shouldn't lie - do I think "old package managers" should show a warning, that their apps are not sandboxed, maybe, but won't happen. I do think we can be better then them and more transparent.

I think we are also missing a chance to 'talk to the user' about why flatpak is more secure in general and how they can request permissions to be tightened up.

That's a great idea, the problem is probably, that it's either commandline to do this or very distro/install dependent (flatseal in gnome, kde settings in kde etc. pp.)

[droidmonkey]

Oh I meant file an issue with the projects flathub repo. I have a couple in mine right now asking to remove the root filesystem access

[secretmango]

I want to agree a lot that it is very important for Flatpak to show a warning. There needs to be a security level where apps are considered safe, and if they are not, they are not. This needs to be clear.

For example there is no secure Video player currently, with Celluloid being the least bad, as it still has filesystem access.

SELinux confined users might help here a bit, but apps need portals, if they refuse, they should be marked as insecure.

[droidmonkey]

I want to agree a lot that it is very important for Flatpak to show a warning. There needs to be a security level where apps are considered safe, and if they are not, they are not. This needs to be clear.

You are mixing security with the arbitrary term of safety. What makes an app safe? Based on the criteria for flatpak mentioned above, almost nothing is safe. When nothing is safe, then nothing is unsafe either. Binary designations are wrong to begin with, but when you lump apps together based on unnecessarily strict criteria you lose any meaning to the word unsafe.

For example there is no secure Video player currently, with Celluloid being the least bad, as it still has filesystem access.

Why is filesystem access insecure? Perhaps video players require this access to do what they need to do. Just because access is requested does not make something automatically unsafe. How the app uses their access could make it unsafe.

SELinux confined users might help here a bit, but apps need portals, if they refuse, they should be marked as insecure.

Portals are not feature complete and there are a ton of missing portals that would help close these 'safety' gaps. But that's not shown to the user so it looks like the app itself is the problem...

[Mikenux]

The system clearly needs to be revised, because even using portals does not mean that an app is "safe". For example, a fully sandboxed app using the file chooser portal is not completely safe, because the app can potentially damage any file given to it. The advantage of the file chooser portal over a static filesystem permission is that the app has access to only the files that the user has chosen to give. Thus, the file chooser portal is more protective of files than a static filesystem permission, but not of the files that are given. Also, I have an open issue to better protect files given via the file selection portal by making them read-only by default. If the app wants to write to files, it will have to ask for it. However, from the moment the user grants write access to the files, we can no longer assume that the files are protected: they can potentially be damaged by the app.

Otherwise, we still need a clear badge that tells users whether they can install an app directly by clicking the Install button, or whether they should pay more attention by reading additional text in case of static permissions. The principle is to have a good user experience where the user must not see lots of text which does not encourage reading... and therefore to install an app without being really informed.

[jonaslomp]

Maybe just change the wording to something like weak Sandbox, strong Sandbox. Weak still has the desired implication not so good, and strong has the implication good. This would communicate more clearly what's measured here, while making it understandable to anyone what's good and what's bad (in case green and red are not clear enough)

[Mikenux]

If most users understand what "sandbox" means, yes. Maybe a user will understand "weak sandbox" as an app being potentially unsafe too... That's something we can't really know until someone is making a study with naive users and different wordings.