Portal to open file and neighbouring files

[hadess]

We're missing a UI that would make it possible to opening a file, eg. a project file, and also give access to the rest of the files in that same directory. This is useful for:

• audio or video authoring with a project file and assets
• video playback where subtitles could be external files

UI-wise we could have:

• post-file selection question "also allow to access the other files in the same directory"?
• checkbox in chooser dialogue "[X] Allow app to access neighbouring files"

New use cases, UI ideas, or prior art? Please list them below.

[hadess]

From https://github.com/flathub/flathub/pull/1415, sqlite would like to be able to write the main db, as well as some files in the same directory such as its journal.

[TingPing]

I wonder if its valuable to limit it to just specific files matching a pattern rather than all of a directory.

[hadess]

I wonder if its valuable to limit it to just specific files matching a pattern rather than all of a directory.

Maybe, for something like video players wanting to access subtitles, but that might be complicated for all other types of projects, where the name/extensions of assets wouldn't be known until the main file was parsed.

[TingPing]

Yeah media players is what I was thinking of, using a pattern could improve the UX, it could know no other files match and just behave as normal without constant double prompts.

[matthiasclasen]

Am I wrong to expect this to be just an option in the OpenFile method of the file chooser ?

[hadess]

Am I wrong to expect this to be just an option in the OpenFile method of the file chooser ?

The priority would be to discuss the UI and the use cases for now, not the implementation. This will tell us whether we want an option for the OpenFile method, or something else. For the media players use case discussed above an option won't be enough, as we need to return multiple files.

[saivert]

I feel this is going to get very complicated. At some point you just have to concede and accept a gaping hole in the sandbox for certain kinds of applications. Music and video apps that need access to companion .cue or .srt files will just need access to the same folder (and subdirs) so they can load those files. Otherwise you need various mechanisms of increasing complexity to allow the portals to figure out which files to give access to.

For fun I could think of using javascript programs that is submitted by the app via the portal API and which will parse the selected file in the file chooser and spit out a list of associated filenames. But for very complex file formats this could be a daunting task. For things like .srt and .cue it should be fairly trivial to write some javascript for that purpose. With very limited API surface in the jvm this could be made perfectly safe and it would only understand a list of filenames coming from the script and it would have to be limited to the folders that the flatpak app currently has permissions to access. Or if not javascript maybe even some DSL that is designed with functions to open, read, seek and do data conversions. Or even BPF.

My skin in the game here is that I currently maintain a flatpak manifest for DeaDBeeF music player. So mp3/cue is something I would like support for opening.

[ptomato]

In case more use cases are wanted: the Inform compiler takes as input a project folder "Foo.inform" (which the user can select with a file chooser in the UI) and expects to be able to create an assets folder "Foo.materials" as a sibling of "Foo.inform".

I think this would be able to be handled by a new option for the OpenFile method.

[somas95]

And more use cases: currently I have to disable the sandbox in Apostrophe because otherwise I can't render a markdown document with images (which are not embedded due to the plaintext nature of markdown)

I can see the same happening for IDEs, which need access to a whole folder, or any kind of editor where data is linked instead of bundled

[teohhanhui]

Another media player use case in https://github.com/flathub/io.github.celluloid_player.Celluloid/issues/28

[Mikenux]

Hello ! It is also needed for playing external audio files (and maybe video files) linked to PDFs (software use here: GNOME Document Viewer [Evince]) in full sandboxing.

[gasinvein]

Apps that run win32 binaries via Wine, e.g. Bottles and protontricks, could benefit from this as well. An .exe can be opened via portal, but if it's not self-contained and require some .dlls in the same directory, it won't work.

[BrainBlasted]

For image viewers like EOG, we want to be able to browse images adjacent to the one the user opens.

[ssokolow]

Aside from GTK applications that haven't yet migrated to GtkFileChooserNative yet, this is probably the number-one reason I have huge exceptions in my sandboxing:

1. Browsers need to read subresources when loading file:// URLs and need to write _files directories when Ctrl+S-ing.
2. MPV needs to read subtitle files when opening video files, and needs to read video files when opening the .edl files I generate to skip ads, sponsor notices, and the odd skit that goes on too long in old Spoony videos. (Currently, I've used overrides to disable MPV's network access and grant host:ro.)
3. Emulators need access to .bin files when they open .cue files
4. Anything that uses SQLite for its container format, for previously stated reasons.

[BrainBlasted]

There's an adjacent issue - when passing a URI (for opening via the file manager or app chooser portal) apps also need a way to handle that. A solution for GtkFileChooser doesn't work for every case.

[WhyNotHugo]

Regarding the UX aspect of this: a clear and non-confusing API for this, is to:

• Use a regular FileChooser to pick a file.
• Application requests access to the portal to read other sibling files (e.g.: via the new API).
• Portal shows a new popup: "Application X wants to access directory /path/to/file/" with allow and deny buttons.
• Application gets access to the whole directory.

Some things I kept in mind:

• A flag to the FileChooser portal is tricky, since a FileChooser will pop up and it's very easy for a user to not-notice that they're being requested-than-usual permissions.
• Asking for access to a directory in the first place is tricky; picking a file often makes more sense than picking a directory. For example, an image viewer might want to pick the first image to view. Picking the directory means starting of on the wrong one.

[WhyNotHugo]

When starting applications that take a file as an argument (e.g.: an image viewer when double clicking on a file in a file manager), it would also be handy to sometimes have access to the directory containing the file.

For example, if I double click on an image, I want an image viewer to render it. But I also want to easily navigate back and forth across sibling images. Having to grant the flatpak access to that whole directory ahead of time is very inconvenient.

The same applies to double clicking on videos which have separate subtitles. This scenario doesn't go via a FileChooser portal, so might be trickier.

[wjt]

There's an adjacent issue - when passing a URI (for opening via the file manager or app chooser portal) apps also need a way to handle that. A solution for GtkFileChooser doesn't work for every case.

Another case where I ran into this: LibreOffice has a Help extension, and tries to open it in the system browser. The browser, if it is also sandboxed, gets access to index.html but not the neighbouring files. #555

[Mikenux]

@hadess: Assuming the goal is to at least always read files, isn't it safe to automatically allow apps to only read files? Isn't the problem in writing files?

[ssokolow]

@Mikenux I assume it'd reduce the threat potential... though there would still need to be some way to allow write access for things like opening a project in an IDE (open the project definition in the root of the project and get access to the rest of the source files) or using "Web Page, Complete" when hitting Ctrl+S in a browser.

[smcv]

isn't it safe to automatically allow apps to only read files?

Is your proposal that the ordinary File -> Open file-chooser should always give read access to the entire directory containing the selected file?

The problem is that we can't guess what the user wants, so a UI for doing this sort of thing would need to be really clear about what is going to happen, to set up the right expectations. Otherwise, anyone whose expectations don't match the reality will be justifiably upset.

If you browse to ~/Pictures/2022/landscapes and open one photo, you might reasonably expect that an image viewer will be able to see other photos in the same directory. But, if you browse to ~/Documents and open ~/Documents/funny picture of a cat.jpg, you might be extremely upset to find that the same application (perhaps a chat app) can now read ~/Documents/banking details.pdf. The portal cannot programmatically tell the difference between your expectations in those two cases.

[Mikenux]

@ssokolow : Of course, there's the case for write access, but if it's possible to not ask the user to read files, that's better. I mean regular users expect to have a dialog asking them to write a file (save) more than a dialog asking them to read a file or directory (open/list).

@smcv: As I just told ssokolow, the goal is to not even prompt the user in case of "read". Regarding your example, are you talking about automatically reading files and the application sending them over the network? If so, if the chat app automatically read bank details.pdf, I wouldn't be "extremely upset" because I wouldn't notice it doing so. If I open this same file with a PDF reader, I don't know what the PDF reader can do with the file. The same goes for pictures that I don't want to "share" without consent. Also, even if you grant access through a dialog box, you are sure that the app wants to read files, but you don't know what the app will do with the files. The only advantage is like in your example: countering possibly malicious readings. So if it is the app reading user files and then sending the retrieved information to the internet, maybe in this case the apps without network permission can get the read access without consent. I'm clearly not an expert, I just think the direction to take is to know the cases better to disturb the user less with dialog boxes...

[hadess]

Implementing this functionality in a way where the user doesn't realise they're sharing more than the file they thought they selected is a non-starter.

@Mikenux You're right that asking less questions is good, but not asking questions at all, or asking questions that aren't understood is clearly worse.

I don't think there's any point discussing this functionality until we know how the UI should be designed. Prior art from other OSes and applications would be useful.

[ssokolow]

So if it is the app reading user files and then sending the retrieved information to the internet, maybe in this case the apps without network permission can get the read access without consent.

@Mikenux The application without network access might have D-Bus access to something that does have network access and can be used to perform an HTTP request for them. It's known as the confused deputy problem and it's one of the reasons defence in depth like this is necessary.

[WhyNotHugo]

isn't it safe to automatically allow apps to only read files?

No, other files may contain sensitive or confidential information, access should never be granted automatically.

I don't think there's any point discussing this functionality until we know how the UI should be designed.

I think it's good to continue enumerating distinct use cases so we can make sure we design in a way that catches all corner cases.

Prior art from other OSes and applications would be useful.

I don't think there is much, but IIRC, on macOS applications can prompt for permissions to access an entire directory, but only for well-known ones. There's also no granularity.

---

I think a good approach UX wise is to use the regular filechooser, and then show a small followup dialog asking for permission to read neighbouring files. This keeps complexity (UX wise) to a minimum, but also makes the extra access request explicit. Being a separate yes/no dialog prevents accidental confusion.

I don't think it can be less than two click when you're asking for two distinct permissions, and granting access must always be explicit (eg: a small checkbox at the bottom of a file chooser is easy to miss).

[ssokolow]

I think a good approach UX wise is to use the regular filechooser, and then show a small followup dialog asking for permission to read neighbouring files. This keeps complexity (UX wise) to a minimum, but also makes the extra access request explicit. Being a separate yes/no dialog prevents accidental confusion.

I don't think it can be less than two click when you're asking for two distinct permissions, and granting access must always be explicit (eg: a small checkbox at the bottom of a file chooser is easy to miss).

That'd be a distinct annoyance and incentive to continue packaging with looser manifest permissions for anything like an IDE where the typical case is going to be granting the entire folder.

I think it's important to keep brainstorming.

(Bear in mind that, from what I remember, the big hold-up for getting things like GIMP and Inkscape onto GtkFileChooserNative is whether they're willing to risk regressing the in-chooser preview pane. Maintainers can be picky about these things.)

[hadess]

I think a good approach UX wise is to use the regular filechooser, and then show a small followup dialog asking for permission to read neighbouring files. This keeps complexity (UX wise) to a minimum, but also makes the extra access request explicit. Being a separate yes/no dialog prevents accidental confusion.

I don't think it can be less than two click when you're asking for two distinct permissions, and granting access must always be explicit (eg: a small checkbox at the bottom of a file chooser is easy to miss).

If either having 2 dialogues, or a checkbox in a dialogue were good enough, then it would already be implemented. It isn't...

[hadess]

That'd be a distinct annoyance and incentive to continue packaging with looser manifest permissions for anything like an IDE where the typical case is going to be granting the entire folder.

IDEs can already use the OpenFolder portal.

[ssokolow]

IDEs can already use the OpenFolder portal.

1. I just gave IDEs as an example.
2. Not all IDEs and IDE-like things use "Folder containing a Well Known filename" as their structure. Some have a project file with an arbitrary name such that you could have multiple projects sharing a single folder.

[WhyNotHugo]

We could have a new permission for Flatpaks that elevantes all "open file" calls to "open file and neighbouring files".

So something like an IDE can [at install time] request this permission, and then any time a file is opened, so it the directory.

This gives really good usability for this kind is scenario, but makes it impossible to open a file without sharing the entire directory.

I do believe there are scenarios where this approach is the one that makes sense the most, but for other type of applications, the second pop up is still best. In reality, the new permission would skip the dialog on the second call and always grant the followup request.