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.

[ssokolow]

Yes. But is there a request somewhere to have something to manage permissions easily?

I'm honestly not sure. The Flatpak infrastructure is such a maze of separate repositories and associated issue trackers that, for the things I've already found an answer to, it's literally taken me months of off-and-on searching to figure out where they're supposed to be reported... usually finally discovering that they already have been in the process, but using that one keyword I forgot to try searching for.

(eg. "Flatpak would really benefit from being able to grant Discord access to publicly routable IPs only, and granting LAN stuff access to the local subnet and non-routable IPs only" "...oh, it's been reported. It's just waiting on reworking the lower layers so that doesn't require root permissions to enact".)

For all Bugzilla's archaisms, that's one thing Mozilla does get right. You pick a top-level product and they'll search for dupes in all contained components and, once you've reported it, triage it into the right one for you.

There is nothing that is dictated, only something that is proposed and subject to discussion. If there is no proposal, there is nothing to discuss, therefore nothing to do. The thing is to have a proposal created by a small number of people (or interactions between people). When you have it, you offer it to others (GTK and QT devs). If they want to collaborate, they will tell you what is possible, what is not and you adjust your proposal. That's basically what we've done here.

Ahh. So we were talking at cross purposes. Sorry about that.

It's not easy as I thought. If we do this, we must request to grant access to the files and folders that the application wants to access. It would indeed be strange to see a dialog asking for access to neighboring files and folders, especially if it is requested when opening the application. Asking before the "Open" dialog wouldn't be consistent either. So, I leave it as it is.

By "on first use", I meant "The first time you click OK in an Open dialog, a second 'Oh, it'd also like access to adjacent files' dialog follows", not "on first run".

(Sort of like how your web browser will pop up a prompt when the website calls the function to request for geolocation information and you haven't said "Yes, remember that" before.)

[Mikenux]

Ahh. So we were talking at cross purposes. Sorry about that. Thank you! Maybe I worded it wrong too, because I didn't understand your "on first use" comment.

As for "on first use", I kept the dialogue. You can see this in the latest mockup below (if there is no "read-only" support in the file picker, nothing is displayed; if there is support, something is shown).

[Mikenux]

To summarize:

• Limit access to file types/extensions. They are mentioned in the manifest. This can be done for every application (even those that need to access more than neighboring files and/or folders). If an app matches a filename (e.g. subtitles), maybe also something to limit access to files that have the matching filename and type/extension?
• Restricted access to folders. They are also mentioned in the manifest.
  • Access to neighboring files folder (folder from which a file is opened). This folder is not displayed in the user interface, only neighboring files are shown. Nothing needs to be defined in the manifest.
  • Subfolders (neighboring folders). Specify "Subfolders" to access all subfolders. Prefer to specify a specific folder if the application only needs to access a specific folder. For example, for web browsers: *_files or, ideally, "get filename"+_files. However, Firefox, for example, translates _files. So, if specific folders are used, remember that they can be translated.
  • Access to subfolders is limited to defined file types/extensions.

[ssokolow]

Sorry for forgetting to reply yesterday.

As for "on first use", I kept the dialogue. You can see this in the latest mockup below (if there is no "read-only" support in the file picker, nothing is displayed; if there is support, something is shown).

I'm not sure the "already has been granted at least one time" dialog is worth the added complexity (both to the programmer and to the end user) of displaying an alternative dialog and requiring that the portal host track that detail when you've never said "Always".

It's like drawing the distinction between "cookies never set" and "cookies cleared".

If an app matches a filename (e.g. subtitles), maybe also something to limit access to files that have the matching filename and type/extension?

The problem there is that, for example, as a lazy convenience to pretty up my launcher for emulators which take CD images, I'll often rename the CUE file to a more human-friendly name without going in and editing it so I can rename the BIN file (which is probably named after the disc's volume label or the Sony catalogue number or something else in that vein).

(There may also be "some other tool uses a hash database to identify these things" reason to leave the CUE file's contents unedited.)

or, ideally, "get filename"+_files

Again, I sometimes rename the .html file without bothering to go in and edit the paths so I can rename the folder.

Given that I'm a programmer and a perfectionist, I imagine this is more common in the general user base than with me.

Kind of reminds me of that "Deleted the _files folder... where the hell did my HTML file go?" moment when I discovered that, on Windows on NTFS, Firefox was using some kind of feature of NTFS metadata to bind them together as a single deletable unit without being able to alter the "Are you sure you want to delete that?" prompt.

(I leave Firefox on "HTML, Complete" and just delete the _files folder when all I want is the HTML since it has no "just this time" option for changing the format to save as.)

Limit access to file types/extensions.    Access to subfolders is limited to defined file types/extensions.

Is this mandatory or optional? I imagine allowing all would be desirable for something like Visual Studio Code which supports a ton of different file extensions even before you install addons... not to mention trying to guess every random non-standard-but-by-convention extension programmers may use for their custom DSLs.

[BrainBlasted]

So: I really think we should keep this very simple. Upon picking a file from the file chooser, a dialog appears saying something like "$APP_NAME wants access to folders and files in this folder. [ Grant Access | Reject Access ]". The main limitation should be something like an app not being able to request full access to $HOME this way. Otherwise, we keep it simple. Allow the app to access the adjacent files and folders for that session if the user allows it. Any other limitation risks requiring more and more specific solutions for different tasks.

[ssokolow]

That would certainly be something that could be refined later... though not having some kind of Remember/Always option would still likely prompt me to just go into Flatseal and open up the manifest permissions to avoid the annoying second click on each Ctrl+S of a Firefox Save As for an HTML file, or whatever else.

EDIT: If I didn't know how to do that, I could easily imagine prompt fatigue setting in, where I stop paying attention to which application is requesting the extra permission and just habitually grant it whenever prompted.

[Mikenux]

@ssokolow:

I'm not sure the "already has been granted at least one time" dialog is worth the added complexity (both to the programmer and to the end user) of displaying an alternative dialog and requiring that the portal host track that detail when you've never said "Always".

It's like drawing the distinction between "cookies never set" and "cookies cleared".

I did this in order for users to know that they have already acted on the dialog and so that there is no confusion with other dialogs requesting access to neighboring files (other applications) because of the same type of user interface (similar appearance). However, this is purely speculative.

Concerning the associations by names, it is also an addition (an improvement for the future for example), but it is only for the applications which act this way. Maybe the web browser example wasn't the best because I didn't know how exactly it worked.

Limit access to file types/extensions.

Access to subfolders is limited to defined file types/extensions.

Is this mandatory or optional? I imagine allowing all would be desirable for something like Visual Studio Code which supports a ton of different file extensions even before you install addons... not to mention trying to guess every random non-standard-but-by-convention extension programmers may use for their custom DSLs.

It is mandatory for better sandboxing. For IDEs, it depends on whether file extensions can be grouped (and identified) as the same type. Maybe something needs to be done here. I also know that GNOME Builder can open directories (the OpenFolder "portal"?), so maybe something can be done on that side (if you also open directories with VS code)?

[Mikenux]

@BrainBlasted:

So: I really think we should keep this very simple. Upon picking a file from the file chooser, a dialog appears saying something like "$APP_NAME wants access to folders and files in this folder. [ Grant Access | Reject Access ]". The main limitation should be something like an app not being able to request full access to $HOME this way. Otherwise, we keep it simple. Allow the app to access the adjacent files and folders for that session if the user allows it. Any other limitation risks requiring more and more specific solutions for different tasks.

My goal is to have stronger sandboxing and let the user know what the app intends to do. If you choose "$APP_NAME wants to access folders and files in this folder. [Grant access | Deny access]", why should I grant access if I don't know what the app intends to do with them?

[ssokolow]

Except that some of the stuff on Flathub is already "We refuse to compromise on user experience, so we're using filesystem=home (or even filesystem=host)".

What you propose would push people with that mindset to decide that granting filesystem=home or filesystem=host is the better choice for want of an "Allow granting * adjacent to whatever $HOME/narrower/scope/... the user pics with their file chooser".

(Remember that, for a lot of people, Flatpak isn't about security first, but about ensuring access to newer packages than their distro offers in the repos... and I saw dispute in the tracker for the Discord Flathub package over whether it should be about security, with people basically saying "You don't want to give people filesystem=home for their file-uploading pending Electron gaining GtkFileChooserNative? I'll be setting an override for that but, if I didn't know how, I'd be dismissing Flathub as not fit for purpose.")

Here's a list of just the things I have installed where my overrides contain !home or !host plus some narrower manifest grants:

• cc.arduino.arduinoide
• com.calibre_ebook.calibre
• com.dosbox_x.DOSBox-X
• com.github.Eloston.UngoogledChromium
• com.github.libresprite.LibreSprite
• com.orama_interactive.Pixelorama
• com.sweethome3d.Sweethome3d
• fr.handbrake.ghb
• io.github.antimicrox.antimicrox
• io.lmms.LMMS
• org.blender.Blender
• org.freedesktop.Bustle
• org.freedesktop.appstream-glib
• org.godotengine.Godot
• org.gottcode.FocusWriter
• org.inkscape.Inkscape
• org.kde.kcachegrind
• org.kde.krita
• org.openttd.OpenTTD
• org.ppsspp.PPSSPP

Granted, the Arduino IDE, LibreSprite, Pixelorama, Sweet Home 3D, Blender, Bustle, appstream-glib, Godot, Handbrake, Inkscape, OpenTTD, and PPSSPP don't delegate to QFileDialog or GtkFileChooserNative or offer their own portal support upstream, but that still leaves Calibre, DOSBox-X, Ungoogled Chromium, AntimicroX, LMMS, FocusWriter, KCachegrind, and Krita.

Arduino IDE, Bustle, Handbrake, and Inkscape appear to use GtkFileChooser, appstream-glib is a CLI tool, Sweet Home 3D uses Swing's Windows 9x knock-off file chooser, Blender, Godot, LibreSprite, and OpenTTD build their own file choosers, Pixelorama is Godot-based, and I'm not sure why PPSSPP needed relaxed filesystem permissions.

(That said, anything GTK-based that doesn't pick up the portal file chooser might be intentionally opting out. For example, Handbrake presents a file picker so you can choose a device or ISO but also puts you in a "needs adjacent files" situation if you want to convert a folder of pre-ripped VOB files as is produced by something like dvdbackup.)

Calibre, AntimicroX, LMMS, FocusWriter, KCachegrind, and Krita are Qt-based. DOSBox-X and Ungoogled Chromium delegate to something portal capable, though the former is SDL-based and the latter uses its own toolkit.

[Mikenux]

@ssokolow: Is your last comment for me? If so, could you explain more simply what you mean (what are the issues)?

[ssokolow]

It's a reply to this:

It is mandatory for better sandboxing. For IDEs, it depends on whether file extensions can be grouped (and identified) as the same type. Maybe something needs to be done here. I also know that GNOME Builder can open directories (the OpenFolder "portal"?), so maybe something can be done on that side (if you also open directories with VS code)?

Basically, I'm saying that, if you don't allow * as a valid filter for what adjacent files to be granted, you're likely to run into various maintainers just sticking with filesystem=host or filesystem=home and bypassing the portal entirely in order to ensure that their standards for end-user experience are met.

It's that whole "If you push too hard, you'll get nothing" dilemma paired with Flathub's emphasis on presenting applications in their upstream forms and maintainers' general unwillingness to effectively maintain a following fork.

[Mikenux]

@BrainBlasted:

"$APP_NAME wants access to folders and files in this folder. [ Grant Access | Reject Access ]".

Here is another phrasings:

• $APP_NAME may want to access folders and files in this folder to work properly.
• $APP_NAME may want to access neighbouring/adjacent files and folders to work properly.

If you want to additionally suggest the user to get information, the simplest would be something like (directly displayed or hidden behind a button):

• See website.web for information on how $APP_NAME works.

[Mikenux]

@ssokolow:

OK. It's no problem to add an "All Files" option. With this, we are then in a "best effort" situation.

However, if the apps don't use a native file picker, neither solution will work (both solutions are after selecting a file to open in a native file picker), unless we don't ask for it (like setting filesystem=host or filesystem=home), or ask before applications open a file (i.e. when the application is launched from its icon or from a file opened from a file manager - maybe that's what you meant with "on first use"?). Or did I miss something?

[ssokolow]

See website.web for information on how $APP_NAME works.

This could easily get long and complex if website.web is something like http://longprojectname.github.io/en/1.2.3r4/manual/part5/chapter6.html (or, more likely, something like https://github.com/joncampbell123/dosbox-x/blob/master/INSTALL.md)

Perhaps a simple, fixed size "more info" link that can be right-clicked to Copy URL if you don't want to open it in the default browser?

OK. It's no problem to add an "All Files" option. With this, we are then in a "best effort" situation.

Flatpak is fundamentally a best-effort solution exploring how far "best effort" can feasibly go. Otherwise, you'd be implementing a capability-based system like WASI.

There's also plenty of precedent for this "allow the maintainers to exercise discretion, then encourage them to be reasonable" approach. That's what filesystem=host fundamentally is.

(Though having a blacklist of particularly sensitive things in $HOME that need to be explicitly un-blacklisted in the manifest if your app is something like a a graphical SSH configurator would also be in line with how filesystem=host behaves.)

A big part of the solution you want is going to be patching flathub/linux-store-frontend to display addons.mozilla.org-style permissions information as part of putting ambient pressure on maintainers who grant permissions too freely, and patching GNOME Software and KDE Discover to display permissions information in a form comparable to the flatpak CLI.

(Last I checked, GNOME Software just had a "Sandboxed" badge even when using filesystem=host, prompting some famous FUD, and KDE Discover just treated APT/RPM/etc. and Flatpak the same, visually.)

However, if the apps don't use a native file picker, neither solution will work (both solutions are after selecting a file to open in a native file picker), unless we don't ask for it (like setting filesystem=host or filesystem=home), or ask before applications open a file (i.e. when the application is launched from its icon or from a file opened from a file manager - maybe that's what you meant with "on first use"?). Or did I miss something?

I was listing them all, then separating the ones that are and aren't relevant. There are effectively four categories:

• Things that just don't use a native file picker at all. (out of scope)
• Things that use GtkFileChooser because they currently customize it, like Inkscape's thumbnail picker and Handbrake lumping a file picker and device selector into a single dialog (out of scope)
• Things that intentionally opt out of the portal because it doesn't offer the permissioning they need (in scope)
• Things that use the portal but set filesystem=host or filesystem=home anyway for lack of the permissioning they need (in scope)

As three examples of stuff among that list of things I personally have installed which are in-scope:

Arduino IDE is an example of something that uses GtkFileChooser or otherwise opts out of the portal but, with this feature, should be capable of being packaged with a trivial patch and an appropriate manifest. (Like something like Visual Studio Code, it needs access to a "project folder" for the file you open.)

Calibre appears to use the portal (Setting QFileDialog::DontUseNativeDialog opts out of the KDE file dialogs by definition, so the Flathub maintainers would have to provide a Flatpak-specific patch to opt out of it), but it imports HTML with associated subresources so it uses filesystem=host.

Cachegrind dumps don't embed all the source they reference, so KCachegrind uses filesystem=host despite using the KDE file dialogs.

[Mikenux]

Totally agree for the More Info link.

Regarding my design, the dialog remains the same. The idea is to have file types/extensions, and recommend developers/maintainers to define extensions before using an "all files" option.

[Mikenux]

(´All files’ is shown in the dialog)

[Mikenux]

@BrainBlasted:

"in order to work properly" might not be appropriate if the application can work without having access to neighboring files and/or folders. Maybe something like "$APP_NAME may want to access neighboring files and folders to work. This access allows to take advantage of all its features.", and a message to let the user know if the app can work without them (e.g. "This app may work without them"). The goal is to make it clear that granting them access makes sense.

[Mikenux]

@ssokolow:

Now, in GNOME Software:

For IDEs:

• With the OpenFolder, you open a specific folder. Here neighboring files/folders are not needed as you are granting access to a specific folder and all its content. In this case, you need to add a specific folder as a project.
• If you modify individual files, neighboring files/folders are not necessary.
• If the IDE has a simple file manager built in (e.g. RStudio), neighboring files/folders are not needed as the application needs to browse the files.
• Maybe neighboring files/folders can be used if you want to modify a specific file in a project folder, but don't want the app to have permanent access to the project folder. However, if you are editing a file and then want to access a file located in the previous folder (for example, this is the case when you directly edit a specific file in a subfolder of the project folder and then want to access the folder project), this requires several access requests, which doesn't seem reasonable to me. I don't think it's worth it in this case.

So for IDEs, do you have any cases where neighboring files/folders would be really useful?

[Mikenux]

@BrainBlasted:

The limitation to specific file types/extensions was there in case you open a file in "parent" folders (home, documents, photos, images, videos) so the app can only read a limited set of files, especially if there are other file formats in those folders that the application is not supposed to open (this will especially be the case for the Documents folder). Note that this is something that can be done (if desired) without having a UI.

[ssokolow]

Now, in GNOME Software:

Good to see they've fixed that. (And I say that with the utmost sincerity. It's worse than useless to say something is "sandboxed" without elaborating.)

So for IDEs, do you have any cases where neighboring files/folders would be really useful?

There are various project tools where they expect you to pick the project file using a file picker... either because it has no standardized filename or to avoid breaking legacy support for "multiple projects intermingled in the same folder".

The Arduino IDE is an example of this that I actually have installed. You pick the .ino file with the file picker, which is a C++ source file with a non-standard extension, and the Build and Upload buttons just assume that, when they launch GCC, it'll have access to what's being referenced by any #include "local_file.whatever" lines you use in your source.

There are also situations such as various Vim configurations where you pick a file, but then you type something like :make or !<command name> and it just runs a vimrc-defined or user-specified command in the working directory of the file you picked, without any form of "project file" as the editor understands it.

(Hell, it's a common approach for me to launch gvim from the command-line or by double-clicking a file and then use Vim's internal Tab-completion, file-finder plugins, or "open selected path" to open additional files in the same project as needed.)

Also, while it's not an IDE, see my previous comment about Handbrake, where the "Open Source" file-chooser dialog is used for both single-file stuff, like ISOs and device nodes and multi-file things, like folders full of VOB+BUP+IFO files dumped using tools like dvdbackup.

[Mikenux]

I added "All Files" now (but I need to tweak some things before posting).

And as I said in a previous comment, the recommendation for developers and maintainers would be to specify all known extensions and use "All Files" as a last resort.

For convenience, I also added the ability to have custom categories to group multiple extensions that don't go together due to different MIME types (it's only to fit the UI I designed).

[ssokolow]

And as I said in a previous comment, the recommendation for developers and maintainers would be to specify all known extensions and use "All Files" as a last resort.

Of course. "All Files" would be to this portal as filesystem=host is to manifest permissions.

For convenience, I also added the ability to have custom categories to group multiple extensions that don't go together due to different MIME types (it's only to fit the UI I designed).

I'll have to wait and see an example to weigh in on that. It could be good or bad depending on how it's designed.

[Mikenux]

For custom categories, I thought of doing the same as for "Unknown Files": orange and invite to click the info button, as well as having a message telling the user that the category name is custom and the list of extensions in the info dialog.

However, this might require a helper tool to check if extensions have a category (like image, video, audio). For example, I just saw that comic archive extensions are categorized as "Other Files" with type "Comic Book Archive" (I'm referring to file associations in GNOME settings). The dev/maintainer checks with the tool if these files have a category (in the tool: enter the extension, and the tool displays it with its category/file type; the dev/maintainer can then use the category /type to show all file extensions belonging to it), and then can decide to put them in a Comics category instead of putting them in an "Other Files" category. Unfortunately, as usual, my knowledge is limited, so I hope you see the thing...

[Mikenux]

Well, I thought about it, and now here is what I think:

@BrainBlasted's design

• I really think it's necessary to have wording to let the user know that the application wants to access the files and/or folders for a reason. For example, "$APP_NAME wants to access nearby files and folders, enabling additional features".
• Perhaps a "More Info" label or an information button that will display text recommending visiting the app's website and/or text describing additional features (e.g. "It is advertised that $APP_NAME has the following additional features:").
• For sandboxing, having at least the choice to restrict access to files, folders, or files and folders. If an application doesn't need access to subfolders, I think it's worth limiting access to only files. In the UI, this would be presented in wording with "files" or "files and folders". Even if it is not displayed, do not exclude the possibility of restricting access with file types and extensions.
• Maybe options like "This time" to always ask, and "Always" to avoid asking each time.

My design

• Go with global permissions (no display of read and write permissions for each file/folder).
• Show in the user interface the file types and folders (global with "Subfolders", specific if necessary with the name of the folders) to be accessed.
• Encourage the user to click only the information button (which shows extensions and subtype when there is no extension) for "Other Files" (old name: "Unknown Files").
• Need a database of file types and extensions. It allows developers/maintainers to simply define extensions in the manifest. Either allow custom categories (if custom, encourage the user to click the info button) or encourage developers/maintainers to improve the database (category approval, "peer review").
• Have the "All Files" option. Optionally have description text (the text in gray) to let the user know it's not ideal (to contrast with dialogs showing a list of specific files).

Note

• The dialog box appears after selecting a file. However, this dialog should also appear if the file is opened from a file manager.

[Mikenux]

• "additional features", or "extra features".

[ssokolow]

For custom categories, I thought of doing the same as for "Unknown Files": orange and invite to click the info button, as well as having a message telling the user that the category name is custom and the list of extensions in the info dialog.

My main concern there is that, if this is a security tool:

1. How do you prevent a malicious app from assigning some sensitive but obscure extension to an innocuous-sounding category, so the user grants permission more readily? (And, if you have guardrails, why not just put that effort into improving the mimetype database that provides the predefined categories?)

2. Weren't you concerned about the height of the dialog? How do you prevent it from becoming too tall? ...especially when a scrollable list in this era of overlay scrolling could hide stuff below the fold?

However, this might require a helper tool to check if extensions have a category (like image, video, audio). For example, I just saw that comic archive extensions are categorized as "Other Files" with type "Comic Book Archive" (I'm referring to file associations in GNOME settings). The dev/maintainer checks with the tool if these files have a category (in the tool: enter the extension, and the tool displays it with its category/file type; the dev/maintainer can then use the category /type to show all file extensions belonging to it), and then can decide to put them in a Comics category instead of putting them in an "Other Files" category. Unfortunately, as usual, my knowledge is limited, so I hope you see the thing...

I think it'd be better to put the effort into improving the shared metadata so everyone can benefit.

I really think it's necessary to have wording to let the user know that the application wants to access the files and/or folders for a reason. For example, "$APP_NAME wants to access nearby files and folders, enabling additional features".

But is that actually gaining you anything or just making you feel better?

I'm reminded of George Carlin's "people add extra words when they want to make things sound more important than they really are." routine where he contrasts "boarding" vs. "boarding process" and "shower activity" vs. "showers"

It seems intuitively obvious that it would enable extra features. Otherwise, why would the application want it? ...and if the "feature" is "stealing your banking information", an extra label like that will just make the request seem more legitimate.

Encourage the user to click only the information button (which shows extensions and subtype when there is no extension) for "Other Files" (old name: "Unknown Files").

Encourage them more, maybe, but those categories can be important to look into regardless.

Some audio or video files are as safe as is possible when parsing untrusted data, while others were made into attack vectors via their container format's "URL where you can get a key for the DRM" metadata. (WMA/WMV/ASF come to mind.)

Some documents are plaintext, while others could contain macro viruses.

etc. etc. etc.

Need a database of file types and extensions. It allows developers/maintainers to simply define extensions in the manifest. Either allow custom categories (if custom, encourage the user to click the info button) or encourage developers/maintainers to improve the database (category approval, "peer review").

My advice is to build on the existing XDG mimetype database that powers file associations via the MimeType=image/x-xpixmap;image/x-xbitmap;image/x-tga;image/x-portable-pixmap;image/x-portable-graymap;image/x-portable-bitmap;image/x-portable-anymap;image/vnd.microsoft.icon;image/tiff;image/svg+xml;image/png;image/jpeg;image/gif;image/bmp;application/x-navi-animation; key in .desktop files by letting the system maintain a central mapping from mimetypes to extensions and/or file headers.

(That'll also make it easier for upstream maintainers to keep .desktop files and manifest permissions synchronized.)

As the Shared MIME-info Database spec details, relying on the system mimetype database will allow you to resolve a mimetype name to:

• A human-readable description (very helpful for explaining what those extensions are in the info sub-dialog)
• An icon, which the user may recognize from seeing it in their file manager, even if they don't recognize the name
• A set of one or more *.foo globs (how they're actually mapped to extensions, which isn't limited to extensions in cases like extensionless ChangeLog or LICENSE/COPYING files)
• A set of magic entries, with optional priority attribute, which define how to identify files based on their headers (This is how things like Nautilus are able to present those "This has a .foo extension but is actually a Bar-format file. Please right-click and manually choose an application from the "Open With" submenu." dialogs.)
• Entries which act as an alternative to magic to allow distinguishing between different XML-based formats.

Here's the example definition from that spec:

<?xml version="1.0"?>
<mime-info xmlns='http://www.freedesktop.org/standards/shared-mime-info'>
  <mime-type type="text/x-diff">
    <comment>Differences between files</comment>
    <comment xml:lang="af">verskille tussen lêers</comment>
    ...
    <magic priority="50">
      <match type="string" offset="0" value="diff\t"/>
      <match type="string" offset="0" value="***\t"/>
      <match type="string" offset="0" value="Common subdirectories: "/>
    </magic>
    <glob pattern="*.diff"/>
    <glob pattern="*.patch"/>
  </mime-type>
</mime-info>

[Mikenux]

The database is not really a security tool. This is to encourage users to inform themseves in case an extension is not known (and that's why I didn't mention the orange color anymore in my last comment).

The support tool is just letting a maintainer/dev check if an extension is known. Because the best is indeed to add extensions to a database (the shared database), they need to know about it. This support tool can be an app or web-based.

It seems intuitively obvious that it would enable extra features. Otherwise, why would the application want it? ...

Sorry, but you can't assume what you think is what everyone else would think. However, if there is an info or "?" button, there will clearly be less need for "additional/extra features" in the wording. With or without the words "additional/extra features", both can potentially encourage the user to click the info or "?" button (if there is one).

and if the "feature" is "stealing your banking information", an extra label like that will just make the request seem more legitimate.

So never use an app:

• If you click "This time", the app can steal your banking information.
• An application doing this will be designed not to work with the neighboring files and folders portal.

Even if you don't have those extra words, what will make you not allow access, and especially if you think it's obvious that requesting access to neighboring files allows extra features?

My plan is as follows for now:

• Let Chris develop the neighboring files/folders portal. I just recommend certain things. The goal is for Chris to be able to develop without having to do too much. This will offer a long-awaited solution.
• If the flatpak devs are interested in what I've proposed, they have all the pieces, including a GUI proposal. I will only continue if they let me know if they are interested (and if further work on the GUI design is needed). This graphical interface (with the mechanics that go with it) may be an improvement over Chris's in the future.

[ssokolow]

Sorry, but you can't assume what you think is what everyone else would think.

I don't disagree with that. However, I think your chosen phrasing is not functionally different from "This program wants these extra permissions so it can use them."

...and the answer is "Oh, thank goodness. I was worried it wanted them because the maintainers just liked requesting more permissions than they were going to use".

...plus, with your phrasing, if they refuse it, the program might crash or display an "ERROR: Couldn't open file. Exiting." dialog... and then you've misled the users.

It feels like performative security without any justification that it has any benefit other than playing into your perception of what's necessary to make people safer and, from my own anecdotal experience, it won't.

I've worked with technically skilled users, with my mother's artist friends, who are now in their 70s or 80s, and various people in between and my experience is that people react in one of three ways:

• They find the fact that they're being prompted inherently unnerving because they're not trained in the minutae of this sort of thing and they know it, so they either call someone they trust to make the decision or they just guess. "This will enable extra features" doesn't help there, because they don't know what those extra features are while being prompted and may make it worse because, if they guess "no", and the program refuses to run, it will make them feel less confident in their ability to use the program at all.

• They feel confident in their ability to use it, but don't have time to deal with this mess and just allow things.

• They are security conscious and will research why the permissions are necessary before granting them.

None of these three cases are helped by a blanket message tying the prompt to "additional/extra" features which may turn out to not be "additional/extra" after all.

(Especially in a case where it's being specified by the manifest on an unmodified build of the upstream source which is likely to either present mysterious failures when the subtitles refuse to display ("I see the file right there!" after forgetting they refused the permissions) or present a cryptic error when you invoke the hitherto under-tested "Managed to open the .project/.cue/etc. but the OS returned failure when trying to open the files it references" case.)

EDIT: Forgot to reply to this:

The database is not really a security tool.

I'd say it's still a better to query the shared mime database rather than giving the application full control.

...and if it's really in that vulnerable a state, you probably need to harden it anyway to prevent one Flatpak application from manipulating the behaviour of other applications outside the sandbox by contaminating the mimetype data through means intended to allow them to declare their file type associations.

[Mikenux]

"additional features" has nothing to do with security... It was only to vaguely give a reason for this request. Don't forget that there is also "More info"... The only security concerns the sandboxing of neighboring files and/or folders (which is not presented to users in any form). Remember that this is only a proposal, not the ideal. I had first suggested "work properly" which was even more inadequate. But, we can do without it with the info/"?" button or the "More Info" label.

...plus, with your phrasing, if they refuse it, the program might crash or display an "ERROR: Couldn't open file. Exiting." dialog... and then you've misled the users.

If an application crashes because it cannot access adjacent files/folders, there are two options for the dev/maintainer:

• Do not use adjacent files/folders.
• Hope Chris includes something to let the app know if it needs access to it in order to work. If the app cannot work without them, the app should quit.

Example (from another design; the phrasing is another thing):

I'd say it's still a better to query the shared mime database rather than giving the application full control.

...and if it's really in that vulnerable a state, you probably need to harden it anyway to prevent one Flatpak application from manipulating the behaviour of other applications outside the sandbox by contaminating the mimetype data through means intended to allow them to declare their file type associations.

The database is queried. The only thing declared in the manifest are the extensions, unless the portal (with the database) can guess what the app wants to open... As for the "custom category" it was to specify the category in the manifest with the relevant extensions in case it is known that the database cannot recognize them or if they are not classified (and this is only informative). There is no access to the database. Declaring which extensions the app wants to open is just telling to flatpak what to sandbox.

[Mikenux]

Based on what has been said (mostly by you @ssokolow), I think the following (having the GNOME desktop and @BrainBlasted's simple solution in mind):

• A reason is always given in the dialogues. For example, if an application wants to take screenshots, this reason is indicated in the title and in the text of the dialog box. However, in this case, we have a specific reason that concerns only one feature. This is not the case with adjacent files/folders. By itself, we're not asking about a specific feature of an app: we're asking about file/folder access. However, access to neighboring files/folders is not an app feature: it is a feature that allows access to other features in an app (unless that app needs it to work properly , such as project file-based applications). An example of enabling a feature of an app is the ability to browse files with an image viewer. It is therefore difficult to know exactly what to do.
• In GNOME design, at least for now, we only have two response options: Deny and Allow. The design with three options breaks this design. Also, I don't know if we can have additional messages or an info button (I don't think so).

So what to do? Here are some thoughts:

• If we assume that the app needs to access adjacent files/folders and it can't work without them, probably best would be not to ask and just have a badge in GNOME software. This will especially be the case for applications based on project files and applications based on a library (for example, a music player).
• If we assume that an application has "extra" features when accessing adjacent files/folders, but can work without it (thus without those "extra" features), we have to ask (and we end up back to the "Why?" problem). For example, an image viewer may work with only one image, but, if allowed to access other files, may also browse images.
  • However, what if some apps need them to work properly, while others can work without them? Also ask in case of apps that need them to work properly? If so, we'll need a message that the app can't work without them. Only ask apps that can work without them, and don't ask apps that can't work without them? Not asking and always assuming that apps - even ones that might work without them - need them?

[Mikenux]

and applications based on a library (for example, a music player).

They don't use adjacent files/folders...

[ssokolow]

Having a required/optional distinction which behaves similarly to how Firefox extensions do, where they're declared in the manifest but some are like the existing filesystem permissions while others are in a "May prompt for..." section would resolve a lot of potential issues as far as user experience goes.

It'd also provide a natural place (flatpak override or Flatseal) for users to customize the required ones. For example, if you have a tool which operates on BIN/CUE pairs and then find yourself manipulating a lot of DOSBox-based GOG.com games where they rename the .bin files to .gog files for some reason.

[Mikenux]

Having a required/optional distinction which behaves similarly to how Firefox extensions do, where they're declared in the manifest but some are like the existing filesystem permissions while others are in a "May prompt for..." section would resolve a lot of potential issues as far as user experience goes.

I don't understand... Do you mean not asking for some files but asking for others, or asking by file type/extension?

[WhyNotHugo]

A reason is always given in the dialogues. For example, if an application wants to take screenshots, this reason is indicated in the title and in the text of the dialog box. However, in this case, we have a specific reason that concerns only one feature. This is not the case with adjacent files/folders. By itself, we're not asking about a specific feature of an app: we're asking about file/folder access. However, access to neighboring files/folders is not an app feature: it is a feature that allows access to other features in an app (unless that app needs it to work properly , such as project file-based applications). An example of enabling a feature of an app is the ability to browse files with an image viewer. It is therefore difficult to know exactly what to do.

This makes perfect sense.

In GNOME design, at least for now, we only have two response options: Deny and Allow. The design with three options breaks this design. Also, I don't know if we can have additional messages or an info button (I don't think so).

This is problematic. A "remember my chioce" is pretty much a must here. I don't think the protocol discussed here should be lacking only due to one DE's missing feature. For one type of application, I want to check that "remember this choice" checkbox. For others I wouldn't.

The protocol should not make it difficult for implementations to potentially have a one-shot / forever toggle (though it's fine for it to be optional on GUI implementation side).

[ssokolow]

I don't understand... Do you mean not asking for some files but asking for others, or asking by file type/extension?

I mean being able to specify something akin to --filesystem in the manifest, but with something along these lines:

• --requires-adjacent-files=<pattern> will display an install-time permission prompt and then assume "Always allow" without displaying a prompt dialog. (For things like a disk image editor/browser/extractor which supports BIN/CUE or BIN/TOC pairs.)
• --prompted-adjacent-files=<pattern> will display an install time "May prompt for permission to ..." section in the permissions prompt and then automatically display such a prompt when using the file chooser portal, to retrofit support onto applications that don't interact with the portal APIs directly.
• To be consistent with how the file chooser portal works, applications which don't declare anything in the manifest may still directly invoke the prompt via D-Bus to support conditionally prompting for elevated permissions. (eg. So they can open a .cue file and then only prompt for the extensions actually referenced by it.)

[Mikenux]

This is problematic. A "remember my chioce" is pretty much a must here. I don't think the protocol discussed here should be lacking only due to one DE's missing feature. For one type of application, I want to check that "remember this choice" checkbox. For others I wouldn't.

The protocol should not make it difficult for implementations to potentially have a one-shot / forever toggle (though it's fine for it to be optional on GUI implementation side).

Be reassured, I never suggested that this should block the protocol (and I think for people who want to, there should be Deny/This Time/Always options in GNOME).

[Mikenux]

So opting for differentiation, depending on whether the application absolutely needs adjacent files/folders or not (as demonstrated by @ssokolow).

• To be consistent with how the file chooser portal works, applications which don't declare anything in the manifest may still directly invoke the prompt via D-Bus to support conditionally prompting for elevated permissions. (eg. So they can open a .cue file and then only prompt for the extensions actually referenced by it.)

Could you give an example?

[ssokolow]

I thought I did with the (eg. ...) that you quoted. Could you elaborate on what kind of example you're looking for?

[Mikenux]

How it works "visually" (the app do this, then do this, the prompt appear at this time)

[ssokolow]

It would look identical to the --prompted-adjacent-files=<pattern> case (Click OK in the file chooser and the neighbouring files dialog pops up), except that it would only happen some of the time because, instead of the manifest indicating that it should happen whenever the file chooser is invoked, the application is reading the file from the file chooser and then manually issuing D-Bus requests for the neighbouring files dialog as needed.

[Mikenux]

Ok thank you. Sounds more or less like what I originally wanted. However, again, the dialog should make sense to the user...

[xhorak]

related bug https://bugzilla.mozilla.org/show_bug.cgi?id=1764700

[Mikenux]

@xhorak:

Neighboring files/folders is about opening files, not writing them: only files or folders that will be opened with the adjacent files/folders feature will be writable.

Adjacent files/folders to write were not discussed. Maybe this is something to be discussed in a new issue or it will delay the coming of the feature discussed here.

@hadess, @BrainBlasted: What do you think?

[ssokolow]

I just assumed it would be supported since:

1. Without it, any of the IDE-like situations that have been discussed will appear to work, but then break in surprising ways when the user tries to use the in-IDE function to create a new file at the top level.
2. Needing to manually whitelist swathes of folders for Firefox's "Web Page, complete" Save As mode is probably the single biggest hole in my sandboxing (since I can't apply my "network XOR filesystem" policy to it) and also the one I invoke the most often.
3. @ptomato's example right up near the beginning is specifically focused on creating a sibling for what the user chooses.
4. SQLite databases need to be able to create and delete siblings because that's how they implement their write journalling.

[Mikenux]

This was something that got overlooked in the process... However, this issue was mostly about opening files, not writing them.

This may work if you open a project file (or folder) first. However, we mostly talked about accessing adjacent files or folders, which assumes they already exist. And by access, we've always meant to open (and indirectly write to files that can be opened). Now it's up to @hadess and @BrainBlasted (who wants to work on it) to clarify on those cases.

Saving a web page and its resources is a different case because you are not opening a file first.

[ssokolow]

Ahh. I imagine we'll probably see things like Firefox, various IDEs, etc. continuing to use filesystem=host or filesystem=home then.

I know that it makes it practically useless for me since most of the things that only need to read stuff still don't use portals (GtkFileChooser, DOSBox's imgmount command, etc.) while the things that would benefit from a security boost most (browsers, code editors, an SQLite database editor GUI, etc.) need to create adjacent files.

(And the ones that could benefit from it are already easy for me to Flatseal into a "read-only access to just my media folder or whatever, no network access" configuration that will gain little, security-wise, from an adjacent files portal.)

[Mikenux]

I assume that with neighbor files/folders, access will be given to the folder where they are located, so write access will also be granted to it. There are only two issues: (1) (for me) the sandbox mechanism is supposed to be triggered by "opening" a file, which rules out the "saving a web page" case, and (2 ) the wording that asks "to access neighboring files/folders", a wording that, to me, does not imply that new files can be created.

If we forget the "save webpage" type case, I guess new files and folders could be created using "adjacent files/folders". However, it will be an inappropriate use of this feature if the wording is not adjusted. So if (1) is correct and (2) is adjusted, it might work. But only flatpak developers can confirm it or not.

For filesystem=host and filesystem=home there is still my proposal with extensions to have some form of sandboxing if desired.

That's the only thing I can say on the subject.

[ssokolow]

(1) (for me) the sandbox mechanism is supposed to be triggered by "opening" a file

I thought it was supposed to be triggered by picking something via org.freedesktop.portal.FileChooser, which has both OpenFile and SaveFile methods... the latter of which, things like Firefox's Ctrl+S delegate to.

[Mikenux]

I really don't know how it works (I'm still not a developer).

The only thing I can say is that it won't be relevant to ask users if they agree to grant "access to neighboring files" when saving a file.

by picking something

Just to be sure (for my understanding), you mean "when a folder is selected"?

[ssokolow]

Just to be sure (for my understanding), you mean "when a folder is selected"?

No. SaveFile requests a file picker so the user can set the output filename. There's a separate method named SaveFiles for generating a directory picker with the intent to save files and letting the application append filenames the user can't edit.

org.freedesktop.portal.FileChooser has three methods:

• OpenFile will display a file chooser which requires you to pick a pre-existing file and has boolean multiple and directory options to control whether you're allowed to select multiple files and whether to display a directory picker instead, respectively. It corresponds to GtkFileChooserNative with Gtk.FileChooserAction.OPEN or Gtk.FileChooserAction.SELECT_FOLDER.
• SaveFile will display a file chooser which lets you select a parent directory and either type a filename or select a file to overwrite. It corresponds to GtkFileChooserNative with Gtk.FileChooserAction.SAVE.
• SaveFiles will display a folder chooser which lets you select an existing directory or create a new one. It corresponds to GtkFileChooserNative with Gtk.FileChooserAction.CREATE_FOLDER.

...but, that distinction aside, yes. I was imagining the dialog would appear when the user clicks OK in the open/save dialog.

The only thing I can say is that it won't be relevant to ask users if they agree to grant "access to neighboring files" when saving a file.

So we adjust the phrasing. Letting a quirk of the phrasing restrict a fundamental concept that the code you're wrapping expects to hold true is a sure-fire way to make what you've implemented irrelevant.