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 flathub/flathub#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 flathub/io.github.celluloid_player.Celluloid#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.

[sergio-costas]

@ssokolow You know what? That's an idea... Not ideal, yes, but at least would allow to use Kicad with the current technology. I'll try to do a patch to implement that. Thanks!

[orowith2os]

Was it suggested to add an extra option to the FileChooser portal to also pull in the entire surrounding directory? This wouldn't perfectly fix this issue, as ideally a filter should be specified, but it would cover it pretty well.

[Mikenux]

@orowith2os:

If you mean to allow access to neighboring files with a checkbox, that will do for advanced users and developers, but not for naive users. Also, one may wonder how to communicate the sandboxing level of the app (the sandbox hole can be big if access to all neighboring files and folders).

[matthiasclasen]

A portal isn't a sandbox hole - the user is giving explicit access to the directory.

But there is certainly a design challenge for making this obvious and non-deceptive.

[Mikenux]

It should be remembered that filters are necessary because an application may have access to the network and/or communicate with other processes or applications. It would therefore be good to remind the user if the application is well sandboxed (or not). But, honestly, who wouldn't give access to a video editing application via a project file, knowing that the user's files are not necessarily ideally organized? In the cases we've seen, we assume that the user will certainly grant access, hence the importance of filters to maximize sandboxing. It's not all about simply requesting access to a particular object (here, neighboring files/folders).

[orowith2os]

My intention is mainly to use an all_surrounding_files option for now, while a more filtered option is worked on, so that the current use cases work out and can migrate later. Some use cases may also just use a wildcard on a filter.

[mcatanzaro]

As has been mentioned already, we'd need some significant way to indicate to the user that the application will receive access to all files instead of just the one you select.

It's probably best to focus on a long-term solution only as no quick/easy solution is going to be significantly easier than however we eventually decide to solve this.

[orowith2os]

A checkbox with the text "Allow access to surrounding files" is pretty vague and would work. It indicates to the user that the surrounding files will be used by the application, and is vague enough that you don't need to have different checkboxes for "all surrounding files" and "some surrounding files".

[Mikenux]

@orowith2os: The problem with a checkbox and vague wording is that we don't know why the application wants to access more files and which ones. A checkbox might be obvious to people who are already familiar with the app (for example, you already know that a video player you've used before can automatically open subtitles for it). That's why we've taken the direction of a dialog box to ask after opening a file. This way, the minimum (i.e. no filters), is "The application has opened 'video.mp4' and also wants to open 'video.srt', 'any other files in the folder'. However , filters can partly help to make more sense of what is being accessed (not just to limit access to the number of files). For example, the developer of the video player put filters to ask to open only subtitle files, and the user would not see in the dialog that the application also wants to open an image file (this case may be an informative video placed in a "resources" folder with other resources for a project).

Also, can we at least agree that project files (and similar) should ask for filenames after parsing a file and moving it to another issue than this one? (and discuss more about the case where the files come from different locations).

[bertob]

I pushed an initial version of UI for this as part of the file chooser mockups. A dialog in a second step seems like the simplest solution, both because it makes the security implications clear, and because it has enough space to fit a proper explanation (as opposed to, for example, a banner).

[Mikenux]

Having thought about it more:

• If this dialog box appears automatically after selecting the file, without the app making a request, it will also appear for files that do not require other files.
• If this dialog box appears when requested by the app, it means that the app may request it at any time, which is not ideal.
• Having the app request the files in a batch would be better, if possible. As already said, on the mockup and here, the apps should adapt. Edit: For "project" files.

[ssokolow]

Having the app request the files in a batch would be better, if possible. As already said, on the mockup and here, the apps should adapt.

I suppose the thing to do then is begin talks with the Qt and GTK devs. My experience has been that portals are far more likely to get used by third-party developers if the're exposed by a widget toolkit API... especially if they're cross-platform apps.

Requiring apps to either add a new dependency or implement appropriate platform detection code and then speak directly to their chosen toolkit's D-Bus binding is a big impediment to updake.

(Hell, it's been enough of a slog just getting various applications to switch from GtkFileChooser to GtkFileChooserNative and, for cases where you don't need to customize the dialog beyond what the portal supports, that's a drop-in replacement which should be a simple find-replace operation followed by a little testing.)

[Mikenux]

GNOME and KDE developers track portal requests and therefore in principle proposals, so they can already see this if they are interested. They just need to communicate back.

I am currently in the process of updating my proposal (it takes time) and I will post a proposal at the same time to express the interest in having the possibility of requesting all files at once.

[Mikenux]

Revised proposal for neighboring images: #1257

Proposal for "project" files (i.e. any file with links to other files in the same folder): #1256

The revised proposal for "name matching" will come later.

Happy new year!

[Mikenux]

Related Files/Folders (Name Matching): #1259

I also opened a discussion about apps using Wine: #1260

The other proposals have been updated and all have a simpler version.

• Neighboring images: Neighboring Files: Neighboring Images #1257
• "project" files (i.e. any file with links to other files in the same folder): File Set Request (Files With Links to Other Files In the Same Directory) #1256

Follow these discussions if you're interested, I won't report anything here unless there is a completely different solution.