Application Safety Assessment Suggestion

[mihnea-radulescu]

Hi,

Firstly, I would like to thank the maintainers of Flathub for guiding me through the application submission process, it was greatly appreciated!

I have noticed today in the Flathub application screen the newly added assessment UI element. As I understand it, it describes textually and graphically the permissions requested in the repository file.

While I value the transparency provided, I am also taken aback at the harshness of the wording and of the visual highlighting, especially related to file system access, e.g. “Unsafe” and “Can read all your data” texts, coupled with the red exclamation mark graphic.

The inferred meaning, based on the current widespread conventions, is that such an app has a high likelihood of being malicious, and a potential user would best steer clear of it. All of the presented elements (the texts “Unsafe” and “Can read all your data”, and the red exclamation mark graphic) are subconsciously remarkably powerful, thus priming the potential user to discard the application.

As is stands, the implementation of this feature hurts both the application developers, who may find it unpleasant for their app to be marked as dangerous, and the users, who will be more inclined to disregard a significant section of the Flathub applications offering because of it.

My suggestion would be to reword the “Unsafe” header to “Potential safety concerns”, “Can read all your data” to the less dramatic and more granular “Has [access type] access to file system entries: [granular enumeration of the requested file system entries]”, and to change the red exclamation mark to a milder orange question mark.

As an extension point to my suggestion, application safety due to requested permissions could be assessed by looking into the permissions in conjunction, rather than in isolation, e.g. an application requesting file system read permissions that does not also request network permissions is virtually harmless, and thus should be granted a different assessment than an application that asks for both permissions.

Thank you very much for reading my suggestion, and please let me know what you think of it!

[razzeee]

Hey, I’m sorry for that. I’ve missed a change in the upstream that I referenced to implement this.

I’ve since patched this this evening and unsafe still exists, but should be impossible to get for now. Your app now likely has the potentially unsafe text with an orange question mark. Which should approximately match how gnome software 45 will show it.

@mihnea-radulescu

As an extension point to my suggestion, application safety due to requested permissions could be assessed by looking into the permissions in conjunction, rather than in isolation, e.g. an application requesting file system read permissions that does not also request network permissions is virtually harmless, and thus should be granted a different assessment than an application that asks for both permissions.

Your not wrong, but the endgame here is, that apps ideally should not have any permissions, but use portals for everything. So it might make more sense to push into that direction if possible.

[mihnea-radulescu]

Thanks razzeee, much appreciated!

[jarek-foksa]

I was also wondering how to get rid of that warning.

The only reason why my app needs access to home directories is so that it could be invoked from the file manager by double-clicking a file. It looks like the only way to get rid of the “potentially unsafe” warning is to remove access to all directories and later ask the user to enable filesystem access with Flatseal. Or perhaps there is a better way?

[bilelmoussaoui]

The better way is to use the file chooser portal Portal Documentation. If your application is using GTK 3, then you can use the GtkFileChooserNative. Starting from GTK 4.10, using the GtkFileDialog would use the portal by default for you. I believe Qt also has support of the file chooser portal

[jarek]

The better way is to use the file chooser portal Portal Documentation. If your application is using GTK 3, then you can use the GtkFileChooserNative. Starting from GTK 4.10, using the GtkFileDialog would use the portal by default for you. I believe Qt also has support of the file chooser portal

If user has already expressed the intent to open a specific file by double-clicking it in the file manager, it doesn’t make sense to ask the user to select the same file again with GtkFileChooserNative.

[HighKingofMelons]

A specific file opened by ‘double-clicking’ it in a file manager can already get forwarded into the sandbox.

The only issues where you would need to give extra file access would be the app needing other files than the one selected or to know the path to file on the host (to show for example).

Just opening/writing to a single file works.

[jarek]

A specific file opened by ‘double-clicking’ it in a file manager can already get forwarded into the sandbox.

Is this forwarding handled by FileTransfer portal, FileChooser portal or maybe by something else?

Electron does not currently support the FileTransfer portal, but according to the documentation that portal is responsible only for drag & drop and copy/paste. I wonder if it is also needed to allow opening files via a file manager.

[HighKingofMelons]

Flatpak file-forwarding just makes use of the documents portal to function.

It essentially just takes a given file path/uri, forwards said file into the sandbox using the documents portal, and then when the program is actually executed inside the sandbox, it just uses the file’s new path/uri instead.

As an example NightPDF actually avoids using any filesystem permissions at all:

NightPDF | Flathub

[jarek]

I installed NightPDF app from FlatHub on Fedora 38 (Workstation Edition with GNOME) and file forwarding does not seem to work. The app just opens a blank document unless I add extra permissions with Flatseal.

Interestingly, the developer can’t reproduce this issue. I wonder for what percentage of Flatpak users file-forwarding is actually working.

[HighKingofMelons]

Ok, so after some testing i think ive found the issue.

It seems that NightPDF doesnt know how to handle file uris correctly, but due to the .desktop file advertising support for uris using %U, flatpak then makes the assumtion that it can pass a file-uri and makes one.

The reason why it works when the flatpak has access to the file through static permissions, is because flatpak then just passes the argument it was given directly, without making a file-uri.

Funnily enough i found an appimage with an older version of the app 1.0.5 (the current one is 2.0.3) which doesn’t have this issue, so thats fun.

I also tested your app and i can when inside the sandbox manually locate and execute your app with a forwarded file, so long as i dont try to do it using a file uri.

And in fact if i flatpak your app locally, but with:

Exec=boxy-svg %f

Instead of

Exec=boxy-svg %u

In the .desktop file.

Opening from the filemanager works fine without file permissions, so i think its a similar case of your app not correctly supporting file-uris, but still advertising that it does by using the %u “field code”.

This has some more on that:

https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s07.html

[jarek]

@HighKingofMelons Thanks! Replacing %u with %f in the .desktop file fixed the problem and now my app is fully functional without any filesystem permissions.