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.

[teohhanhui]

@WhyNotHugo:

I agree on the sentiment, but you can't know that the file is playlist before opening it. Not unless the portal itself is capable of recognising filetypes -- but that sounds like a pretty big rabbit hole.

Then applying your reasoning for (1), a media player can be assumed to always need to be able to open playlist files, if we already assume that IDEs always need to be able to open project files (not true; one might very well just open a directory or individual files).

[Mikenux]

One thing all of these apps have in common is to automatically open files:

• From opening a file (eg. .cue, project files, etc.).
• From file (from link; e.g. links in PDF or html files, including loading resources for previewing a markdown file).
• Note: the files are not necessarily in the same directory.

The portal should intercept this automatic opening of files. This, combined with a knowledge database of file types (e.g. document, image, audio, video) and file extensions, the user interface could be like this:

• Present a dialog to the user stating that "AppName would like to load the following file(s):".
• If there are not many files (for example, three maximum), present to the user the name of the file (with its extension), the file type, and possibly the complete name of the extension.
• If there are many files to open, present the user with this for each file type (possibly as a list): "[number of files] + [file type]. Example: 3 Images, 4 Documents , 2 Videos, 2 Audio .
• If a file type/extension is unknown, present it to the user first (at the top of the list, perhaps with a color or symbolic warning icon). Example: 2 Unknown file type/extension: .XYZ. It is recommended to obtain information about it.
• Also have the option to see the details: all files to be opened (names with extension), what is the file extension (full name) and any other relevant information.

Never grant read access to a directory. For example, if a user saves a website in their Documents folder, unless there is a database associating each directory with each file type/extension, access will be granted to the directory where the file is located (so the Documents folder). This way the application can read all files in this directory and this is not acceptable. Same if the website is saved in a dedicated Sites folder: the app cannot access another website.

[Mikenux]

I noticed that what I wrote only applies to apps that have file locations in the file they open.

For apps that don't have the location of the files, like a video player opening a subtitle file by matching its name with that of the opened video file, maybe the portal can only allow the app to read the current directory (where the first file was opened), but this access must only authorize the application to read the names of the files, not to open them.

[ssokolow]

Now you're getting into stuff that's more difficult to retrofit onto existing applications (especially by packagers/maintainers, rather than upstream) and, thus, starts to lean more toward aspirational API design.

For example, preflighted "prompt for all listed files in a playlist" requests are a big change from more typical "fopen(3) the playlist, then fopen(3) the entries in it one-by-one to read their metadata... then fopen(3) individual files on demand when starting playing"

...and that assumes it's not some situation where you're doing streaming parsing of a large file, opening sub-files as necessary, similar to how POSIX has opendir(3) and readdir(3) rather than some kind of listdir so you can start presenting a listing of a directory immediately, even if it's something like ~/.cache/thumbnails/normal where retrieving the entire list could take a significant amount of time.

[teohhanhui]

I think we need to be clear what we want to achieve here. It's to allow forwarding adjacent files / directories when forwarding a file through the document portal, right?

MIME type registry etc. seems way out of scope?

[Mikenux]

@teohhanhui : The goal is to have a user interface to access neighboring files. However, for me, it is also about thinking about security and the user in the design of this UI (because flatpak is what it is intended for). I came up with a user interface with security in mind - and thus giving information to the user rather than just asking to access other files or access a directory without any information that might make sense to users . Unfortunately, for the rest, I am not a developer.

@ssokolow : I tried to come up with something. However, I'm not a developer, so I'm not able to consider everything without any information (and I didn't understand what you said).

Be aware that some project files, such as project files for video editors, may need to access multiple directories because the assets users add to their project may not be in the same directory. Thus, users will, for example, have to grant access to the Videos, Pictures, and Music folders.

[ssokolow]

I tried to come up with something. However, I'm not a developer, so I'm not able to consider everything without any information (and I didn't understand what you said).

It's technically impossible for the portal to infer a list of files to prompt for because the standard way OS APIs and applications negotiate to open or read metadata on a file makes opening a list of files indistinguishable from "I'll decide what to open next based on the contents of the first one, same for the third and fourth and so on".

They're blocking APIs. The application stops executing and waits for the result of opening the first file before continuing on to the line where it requests the next file be opened. If you do something sneaky like claiming it's been opened but deferring the block until an attempt to read from it, then you wind up with crashes and data corruption from applications that take "successful open" to mean "I have permission to read/write this" and start modifying things they already got permission for accordingly. (And stuff along those lines.)

(And that's impossible to write a declarative manifest for in the general case, because, while it's a bad idea, an application could easily generate the filename it wants to load next by concatenating a string from inside the file it opened first with some string received from an HTTP request and then hashing the result using MD5 or SHA1 or some proprietary hashing algorithm.)

...and requiring programs to redesign themselves to use new APIs that do take lists of files is about as likely to succeed as Microsoft's efforts to push application developers to migrate from Win32 to UWP APIs.

(Microsoft found that, to get any appreciable uptake of UWP APIs outside of "I want to build this for Windows and XBox", they had to allow "The New Hotness" to be usable without giving up on the "Old And Busted" APIs everyone didn't want to be forced to burn a ton of energy migrating away from. I've seen them talking about plans to cut the Windows kernel in half, with the bare-metal kernel having no Win32 support and the kernel running the Win32 personality only having drivers for a specialized virtual machine and RDP variant used to integrate the apps similarly to what WSLg does.)

Flatpak and XDG Portals are, by their very nature, the same sort of endeavour. Otherwise, you'd see a lot more of a push to stabilize GUI APIs for WASI and have everyone rewrite their applications for that. Capability-based security from the ground up is always going to be more secure than an in-flight retrofit like XDG portals.

Be aware that some project files, such as project files for video editors, may need to access multiple directories because the assets users add to their project may not be in the same directory. Thus, users will, for example, have to grant access to the Videos, Pictures, and Music folders.

That's sort of already covered by the fact that file/directory chooser portal can do persistent grants, so the following three situations are possible:

1. The user uses an OS-provided file picker to select a file to copy into the project. No special considerations are needed and the grant goes away when the application exits.
2. The user uses an OS-provided file picker to select a file to link into the project without copying. They see it without sandboxing. The application stores a /run/user/1000/doc/... path to the file in the project file which remains valid permanently. The only situation where this is less robust than usual is if they restore the exact same filesystem layout from backups but don't restore a backup of the document portal's grant database. (eg. if they're only backing up $HOME)
3. The user uses an OS-provided directory picker to select which directories should be scanned to populate their editor's asset browser. The application stores a /run/user/1000/doc/... path to the directory in the configuration file.

This is how some of the game engine reimplementations on Flathub prompt the user for the location of the game data files with a privileged directory picker on first run and then remember it.

Beyond that, you're getting into "We can't solve the halting problem, so why invent stronger compile-time checks?" territory.

At some point, to guard against fatal scope creep, the only thing you can really do is declare some things "out of scope". As Voltaire said, "The perfect is the enemy of the good".

[Mikenux]

@ssokolow :

2. The user uses an OS-provided file picker to select a file to link into the project without copying. They see it without sandboxing. The application stores a /run/user/1000/doc/... path to the file in the project file which remains valid permanently. The only situation where this is less robust than usual is if they restore the exact same filesystem layout from backups but don't restore a backup of the document portal's grant database. (eg. if they're only backing up $HOME)

In this situation, there is no problem if no other file is accessible. I thought these files were read from the direct filesystem (like /home/XYZ). However, this is automatic file opening in the case of project-type or list-type files (e.g. .m3u) - files containing the location of the files to be opened. In this case, granting access is not really necessary because you have voluntarily added files in your project. So by doing this you have already granted access. Also, you saved the project file, which means you know what file types you added and what the project file is. Maybe just warn when the user uses the project file in another app (due to compatibility) - but that's another topic.

3. The user uses an OS-provided directory picker to select which directories should be scanned to populate their editor's asset browser. The application stores a /run/user/1000/doc/... path to the directory in the configuration file.

This is where my problem lies. You sandbox a directory, but can the app read all the files in that directory and then send them over the internet? If so, that's problematic. In the case of game data files, there are only game-related files in this directory because games place all of their files in specific directories. Thus, by providing access to a game directory, you only provide access to files related to the game, and no other files. The thing is, if you launch a game, it makes sense to give it access to all of its resources. Ditto for folder-based projects: for example, all the files to build an application are in the same directory. We can therefore reasonably assume that you want to use all of these files. However, you cannot assume this for the Documents, Video, Music or Pictures folders: if you give access to these directories, you give access to all the files they contain, thus the possibility of reading and sending them all on the internet, no? The thing is, you don't want to give an application access to all files, only required files. Here we are in the case where the auto-open comes from the application after opening a specific file that does not contain the location of the next file (i.e. the application uses name matching , such as .cue-.bin files, video-subtitle files).

[ssokolow]

You sandbox a directory, but can the app read all the files in that directory and then send them over the internet? If so, that's problematic.

That's like arguing against the camera portal because, if a user grants permission to access the camera, an app like Zoom could be compromised to spy on them. The directory mode for the file chooser portal already exists. Applications can already present a directory picker and then do anything they're permissioned to do with what you pick for it.

An application with network access could already do a "wetware hack" (i.e. a "the human is the weakest link" attack) where it asks for the user's home directory so it can... say... read your shell aliases from the rc files for all supported shells. (As a Zsh user, I can tell you that Zsh has about half a dozen of them which get sources in various situations and at various points in the shell's lifecycle)

There's a limit to how far the trade-off between security and convenience can be pushed.

However, you cannot assume this for the Documents, Video, Music or Pictures folders: if you give access to these directories, you give access to all the files they contain, thus the possibility of reading and sending them all on the internet, no?

You seem to be missing something here. What do I do for lack of this functionality now? I install Flatseal, go in there, and manually and permanently grant permissions to the folders in question. Hell, for MPV, I granted host:ro and turned off network access because I'm technically skilled and security-conscious, but I have things like .mpv.edl files which reference .mp4 files in places like /srv/fservroot and ~/Documents and /mnt/Seagate_10TB and I'm only going to use the Flatpak-distributed MPV if it's not a usability regression.

Hell, if I hadn't coded up a workaround for those Tab-completion-hostile reverse-DNS command names Flatpak exports, I'd be using an APT-installed version instead.

Likewise, if I actually used Blender and Makehuman together more than once in a blue moon, I'd remove the Flatpak version and install the PPA version because the way Makehuman's Blender integration works is fundamentally incompatible with Flatpak runtimes (the communication protocol references texture/model paths stored in the non-Flatpak /usr/share) and manually exporting from one and then importing to the other gets old fast.

What you don't seem to understand is that technologies based on XDG portals, like Flatpak, are not in a position to dictate terms to users or to third-party developers. That's why you see various things on Flathub which set filesystem=home or filesystem=host in their manifests. Many Flathub-distributed apps follow a philosophy of "only take advantage of the security features which are polished enough that the user won't realize anything is different. A leaky sandbox is better than driving them back to the 'no sandbox at all' situation that Just Worked™ for them... especially when they might only care about Flatpak as an easier way to get up-to-date package versions".

Heck, GIMP and Inkscape are dawdling on supporting the XDG portals because it'll regress the in-file-picker preview support for formats like .xcf.

Here we are in the case where the auto-open comes from the application after opening a specific file that does not contain the location of the next file (i.e. the application uses name matching , such as .cue-.bin files, video-subtitle files).

First, BIN/CUE pairs don't use name matching. Here's the contents of game.ins (a renamed .cue file) from whatever version of GOG.com's release of One Unit Whole Blood I have installed, which their bundled copy of DOSBox is set up to mount as a virtual drive:

FILE "game.gog" BINARY
  TRACK 01 MODE1/2352
      INDEX 01 00:00:00
FILE "blood02.ogg" MP3
  TRACK 02 AUDIO
      INDEX 01 00:00:00
FILE "blood03.ogg" MP3
  TRACK 03 AUDIO
      INDEX 01 00:00:00
FILE "blood04.ogg" MP3
  TRACK 04 AUDIO
      INDEX 01 00:00:00
FILE "blood05.ogg" MP3
  TRACK 05 AUDIO
      INDEX 01 00:00:00
FILE "blood06.ogg" MP3
  TRACK 06 AUDIO
      INDEX 01 00:00:00
FILE "blood07.ogg" MP3
  TRACK 07 AUDIO
      INDEX 01 00:00:00
FILE "blood08.ogg" MP3
  TRACK 08 AUDIO
      INDEX 01 00:00:00
FILE "blood09.ogg" MP3
  TRACK 09 AUDIO
      INDEX 01 00:00:00

(game.gog contains only the data track, which I think effectively makes it a renamed .iso file that's also technically a valid .bin file. It's been a long time since I played with that stuff and can't remember whether .iso is MODE1/2352 off the top of my head.)

Second, do you really think it's practical for a package maintainer, who probably isn't the media player's developer to... for example, replicate the media player's hard-coded lookup table of .<lang>.vtt mappings for all 136 of the ISO 639‑1 language codes?

Bear in mind, that's just one subtitle format... the WebVTT files that youtube-dl dumps. I remember playing around with VobSub (.sub + .idx), SubStation Alpha (.ssa), Advanced SubStation Alpha (.ass), and SubRip (.srt) back in the early 2000s, and Wikipedia lists 18 "common" extensions (one of which is .vtt, which explodes into over a hundred .<lang>.vtt names) and mentions that there are tons of lesser-known ones.

This rapidly becomes "and you wonder why the package maintainers aren't in a hurry to be responsible for getting the systemd sandboxing rules right for the things they package, and just leave the daemon un-sandboxed."

A sandboxing solution is no good if it's so obsessed with chasing perfection that it produces a system that gets no uptake. (I'm reminded of how Android is the main place you see SELinux not only being in use, but set to enforcing mode rather than auditing mode, because it's the only place where the vendor could build another platform on top of it and treat the POSIX APIs as officially unsupported implementation details.)

[Mikenux]

That's like arguing against the camera portal because, if a user grants permission to access the camera, an app like Zoom could be compromised to spy on them. The directory mode for the file chooser portal already exists. Applications can already present a directory picker and then do anything they're permissioned to do with what you pick for it.

For the camera portal: No, it's not like arguing against the camera portal. With it, you grant or deny access to the apps you want. With directory mode, as I said before, it is intended for applications where all files related to the application (e.g. a game) or a given function (e.g. code development/building application) are located in this folder. If this mode is used as another function than that, that's another thing...

However, you cannot assume this for the Documents, Video, Music or Pictures folders: if you give access to these directories, you give access to all the files they contain, thus the possibility of reading and sending them all on the internet, no?

You seem to be missing something here. What do I do for lack of this functionality now? I install Flatseal, go in there, and manually and permanently grant permissions to the folders in question. Hell, for MPV, I granted host:ro and turned off network access because I'm technically skilled and security-conscious, but I have things like .mpv.edl files which reference .mp4 files in places like /srv/fservroot and ~/Documents and /mnt/Seagate_10TB and I'm only going to use the Flatpak-distributed MPV if it's not a usability regression.

Assuming most users are unfamiliar with permission management, they won't use Flatseal.

What you don't seem to understand is that technologies based on XDG portals, like Flatpak, are not in a position to dictate terms to users or to third-party developers. That's why you see various things on Flathub which set filesystem=home or filesystem=host in their manifests. Many Flathub-distributed apps follow a philosophy of "only take advantage of the security features which are polished enough that the user won't realize anything is different. A leaky sandbox is better than driving them back to the 'no sandbox at all' situation that Just Worked™ for them... especially when they might only care about Flatpak as an easier way to get up-to-date package versions".

Some developers may work with upstream to better support flatpak. The ease of doing so is another thing. Flatpak's flexibility in terms of permissions doesn't stop you from having something better. If Flatpak developers can develop something better and upstream app developers need to use another API, they will if they want their app to be more labeled as safe. If they don't want to use it, their app won't have a high safety score.

[ssokolow]

If this mode is used as another function than that, that's another thing...

However, it's neither practical nor conceptually correct for the existing portal's directory mode to be second-guessing things when an application calls QFileDialog::getExistingDirectory and Qt redirects it through the portal without so much as a "by your leave".

If you try that, you're likely to wind up with Qt being patched to become more like GTK+, where you need to manually migrate from GtkFileChooser to GtkFileChooserNative and, even if you do that, it won't go through the portal unless something/someone sets the GTK_USE_PORTAL environment variable.

Likewise, that's why filesystem=host and filesystem=home get used. Because the maintainers don't want to risk making a bad first impression when someone's trying Flatpak for the first time. For a lot of people, convenience and "it just works" is the selling point.

Assuming most users are unfamiliar with permission management, they won't use Flatseal.

No, they'll just decide that the Flatpak-provided version is "broken" or "crippled" and go looking for an alternative.

Some developers may work with upstream to better support flatpak. The ease of doing so is another thing. Flatpak's flexibility in terms of permissions doesn't stop you from having something better. If Flatpak developers can develop something better and upstream app developers need to use another API, they will if they want their app to be more labeled as safe. If they don't want to use it, their app won't have a high safety score.

Again, you're putting the cart before the horse. There are no "safety scores" yet... or at least none that were mentioned in the news sites I follow. Hell, KDE Discover doesn't mention sandboxing at all when using the Flatpak plugin, and GNOME Software has received a lot of FUD for providing a simple "Sandboxed" badge which is worse than useless because it gives a false sense of security when, IIRC, "filesystem=host, but run in Flatpak" is enough to trigger it.

Aside from that, you're still arguing about prescriptive decisions where I'm arguing about "How do we make it possible for applications to even use the portals to achieve what they're unwilling to regress the usability of, rather than using filesystem=host or filesystem=home and options like GtkFileChooser or QFileDialog::DontUseNativeDialog? Personally, as a developer, I'd start out a bit reluctant to take on the extra hassle of maintaining something that bypasses the portability abstractions Qt or GTK will give me, so it has to have a compelling value proposition beyond just 'Please do the work to add your project to this new distribution mechanism we are enthusiastic about, and also please write an arbitrary number of patches to satisfy the speculative users you will gain'."

[Mikenux]

@hadess: Apparently we have "high security - applications should be modified upstream" versus "acceptable level of security - modifying applications as little as possible, but making no modifications is preferred". So the UI seems implementation dependent... So which direction to take?

[ssokolow]

Bearing in mind that this stuff is by no means the first to market... it's just hard to get uptake for something that requires modification of upstream. Heck, it's a hassle just wrapping existing .deb or .rpm-packaged things in a sandbox provided by Firejail compared to using Flatpak. It's a chicken-and-egg problem that is made much easier when you can on-ramp the ecosystem with improved-but-not-perfect security that can be made better incrementally by adding new sandboxing features.

[Mikenux]

To sum up how the applications work, can we say that we have:

1. Applications that open files by reading their locations in a file (including files like markdown files where you can write file URLs - but also works by writing URLs that aren't the current folder???).
2. Applications that open files by matching the name of the first file opened (for example, the application opens a video and then searches for subtitle files that match its file name). Are there any mechanisms other than name matching? Note: If the opened file is a PDF which is in a folder (e.g., Issue1), but which contains a link to a "table of contents" PDF which is not in the same folder (ToC.pdf, then folders Issue1, Issue2, etc.), then giving access to the current folder can't work. But this is an exception.

[Mikenux]

Here's a suggestion - let me know if this can work without modifying the apps themselves:

Two things: (1) Info file, (2) User Interface.

Info file

Have an info file containing the following information:

• File extensions that can be opened (this can be used to limit the use of files in a folder).
• Reason why the application wants to access other files in a folder. If users don't know why an app wants this access, they may have no reason to grant it.

User Interface

The user interface is a dialog that appears either when the application is first opened or before opening the file picker when users click an "Open File" type button. When the file is open from a file manager (if this is the first operation performed), the dialog box appears before opening the file with the application.

This dialog asks users if they want to grant access to neighboring files/folders while giving the reason for this request. The reason is taken from the info file. Example:

• AppName needs to access neighboring files and/or folders for the following reason:"
• Text describing the reason
• "Grant access always or temporarily for this session?"
• "Always" and "Temporarily" buttons.

Application examples:

• Image viewer needs to access neighboring files for the following reason:
  • Browse through images.
• The video application needs to access neighboring files for the following reason:
  • When a video is opened, its subtitles can be automatically loaded.
• Note: When an application automatically opens files from a given file, the reason is given by mentioning the events (how the application deals with) in order (first file opened, next files/folders to be opened) .

Open:

• Mention and give information about file extensions?

Neighbor files will not work with a project file if that project file contains files from different locations. This is for example the case of video editors.

[Mikenux]

Giving a reason may be too much. Maybe just mention file types and extensions, and maybe some info about them (or invite the user to learn more about them in relation to the application).

[nbenitez]

The lack of a neighbouring portal is why Evince is setting filesystem=host in its flatpak, for Synctex support it needs to access a .synctex file with the same name and in the same dir of the opened pdf document.

Ideally the neighbouring portal would allow for file extensions, so we could say *.synctex

Thanks for working on this!

[Mikenux]

Example:

[ssokolow]

@Mikenux

Even knowing what issue your example is posted on, it's hard to connect that phrasing to "When you open a file, Vidim Viewer will be automatically granted permission to access the following types of adjacent files within the same folder."

The phrasing you chose feels more like some confusing offshoot of the MimeType key for .desktop files, concerned with somehow closing some vulnerability in "double-click things in the file manager" file associations by not allowing the application to become visible to ~/.config/mimeapps.list until you OK it.

[WhyNotHugo]

The wording is tricky to get right. Maybe something more along the lines of "XXX would like to access other files in DIRECTORY".

This is somewhat less granular, but has an easier to convey meaning.

[ssokolow]

That sounds like you'd be prompting once for each folder. Maybe something closer to "When you open a file, XXX would like to access other files adjacent to it:"

[ssokolow]

Possibly with some kind of "?" button that explains why this kind of situation may be necessary, including examples like a video player accessing subtitle files next to the selected video file.

[WhyNotHugo]

Yes, I would prompt once per directory. I guess you can have an "always allow" button if you want to avoid that, but I think usually you'd want to grant only for the current scenario.

macOS has a similar prompt when an application wants to access specific directories (eg: photos), where the prompt asks for access to all Photos (eg: no subdirectories).

Following this idea, maybe instead of asking for the current files directory, it would make sense to ask for the parent XDG user dir.

[ssokolow]

It's more that, if I was running the risk of having to click "Allow" every damn time I clicked OK on the Open dialog (in the worst case of each file being in a different folder), I'd probably just open up Flatseal and loosen the manifest.

(And users who don't know what's going on would likely see it as a pointless, annoying waste of their time.)

Prompting every time for something that's likely to happen often is likely to encourage prompt fatigue, training users to either relax security or click Allow without thinking, leaving you worse off than if you'd just settled for less ambitious protections.

[ssokolow]

What I envisioned was more along the lines of an install-time/first-run prompt so maybe include a prominent "This Time/Always for This Folder/Always For All Folders" choice in the prompt so the user gets to choose what kind of prompt it is.

[Mikenux]

Yes, the phrasing is not ideal.

The goal is indeed to be general.

I think adding an example would be too much, even hidden behind a "?" button. I prefer that we stay as short as possible.

Following this idea, maybe instead of asking for the current files directory, it would make sense to ask for the parent XDG user dir.

The goal is to restrict access as much as possible, in this case to a “current” folder. Global limitation to file types/extensions and specific folders would be more of an improvement over accessing all files and folders when an application cannot be limited to using files/subfolders in the current folder.

"This Time/Always for This Folder/Always For All Folders"

Asking "Always for This Folder" only makes sense if asked after opening a first file. This will only work if you want to open a file from the file manager. I assume it won't work if you open a file from the app as it may block the automatic opening.

[ssokolow]

Asking "Always for This Folder" only makes sense if asked after opening a first file. This will only work if you want to open a file from the file manager. I assume it won't work if you open a file from the app as it may block the automatic opening.

I was interpreting the suggested "XXX would like to access other files in DIRECTORY" to mean the plan was to have it appear after you clicked OK in a portal-provided file picker.

[Mikenux]

I was interpreting the suggested "XXX would like to access other files in DIRECTORY" to mean the plan was to have it appear after you clicked OK in a portal-provided file picker.

Sure. I just noticed it by adapting the mockup a bit.

Currently, the title is now (for example) "Allow access to adjacent files in Multimedia folder?". The other option is to have the title "Allow access to adjacent files/folders?" and have the folder name in the text. However, I'm wondering how to get the answer "Always for all folders"... This answer wouldn't make sense for accessing a given folder (by itself). Either way, the answer is too long. Or maybe you were talking about having this in the text and not as an answer?

Moreover, even if in the text, when to ask to always give this access to all folders?

[Mikenux]

[Mikenux]

[ssokolow]

automatically or by request

I still think this part confuses things.

What the heck is the point of this dialog, if not to be the "by request" to pre-emptively grant permission for the "automatically" part?

It's like saying "Will you grant permission for it to ask permission?". The fact that it may prompt again later is a sibling to this prompt, not a subordinate.

Access to other files in Multimedia folder?

I have a lot of folders containing media files with titles much longer than "Multimedia" so you'll probably want to rethink that aspect of the layout.

Apply whatever the folder

As I start to read this sentence, my brain anticipates it's going to be "Apply whatever to the folder", as in "Apply [thing] to the folder".

"Apply to all folders" is much clearer.

Also, it's a bit of a confusing checkbox, since it's unclear whether it just means "Remember my choice" (which would be a better phrasing but makes it very easy to accidentally forbid the dialog from popping up again when there's no easy-to-find "permissions editor" control panel to undo it) or only applies to "Always"... and what does "This time" mean if you choose "Apply whatever the folder?"

Maybe a radio button set with "This time", "Always for this folder", and "Always for all folders" and then just have OK/Cancel buttons at the bottom?

[Mikenux]

@ssokolow:

"by request" was in the case where an application announces to the user that a file will be opened (for example, a pdf viewer could announce to the user that a clicked link opens a file). But, let's remove it unless someone thinks something like this is informative.

I have a lot of folders containing media files with titles much longer than "Multimedia" so you'll probably want to rethink that aspect of the layout.

Sure. Also, I forgot to add "and folders" in the title in the "subfolders" case.

Maybe a radio button set with "This time", "Always for this folder", and "Always for all folders" and then just have OK/Cancel buttons at the bottom?

Unfortunately, this would give more height to the dialog...

[Mikenux]

I am now concerned about permissions. Currently, there is only "Read" access. However, there can also be "Write" access. For example, this is the case of an image viewer that browses files and has editing capabilities (@BrainBlasted). I want to know if we can assume that write access goes hand in hand with read access (read and write) or if there can be cases where write access can apply to files different from those with read accesses. Also, in the case where read and write access are separated (even in the case of read and write), do we need to separate the permissions of those accesses?

[Mikenux]

[ssokolow]

I am now concerned about permissions. Currently, there is only "Read" access. However, there can also be "Write" access. For example, this is the case of an image viewer that browses files and has editing capabilities (@BrainBlasted). I want to know if we can assume that write access goes hand in hand with read access (read and write) or if there can be cases where write access can apply to files different from those with read accesses. Also, in the case where read and write access are separated (even in the case of read and write), do we need to separate the permissions of those accesses?

Why not go for consistency with the manifest :ro and :rw suffixes there?

[newest images]

That works, but my concern is that having For "ImageAndVideoFiles" folder and For Vidim Viewer might lead users to interpret For "ImageAndVideoFiles" folder as "Grant all applications permission for this folder". Yeah, it's a little odd to someone used to how these permissions systems are intended to work, but I can easily see it being how non-technical people interpret it.

[Mikenux]

@ssokolow:

Why not go for consistency with the manifest :ro and :rw suffixes there?

My concern is the height of the dialogue. I originally thought there were "Read", "Read & Write" and "Write" categories, but having only "Write" doesn't make sense. Imagine a media player that plays videos and can view and edit images. We would have "Read - Videos, subtitles" and "Read and write - Images", plus possibly "Unknown files" in both cases. This would add height to the dialog box. Also, if anyone is concerned about not granting write access to files - only granting read access, we need something to handle that, or we assume the user must give access to what is offered. What do you think?

That works, but my concern is that having For "ImageAndVideoFiles" folder and For Vidim Viewer might lead users to interpret For "ImageAndVideoFiles" folder as "Grant all applications permission for this folder". Yeah, it's a little odd to someone used to how these permissions systems are intended to work, but I can easily see it being how non-technical people interpret it.

I'm trying different things, thank you so much for taking the time to give me your feedback so regularly :smile:

Thanks also to you @WhyNotHugo!

[ssokolow]

My concern is the height of the dialogue. I originally thought there were "Read", "Read & Write" and "Write" categories, but having only "Write" doesn't make sense. Imagine a media player that plays videos and can view and edit images. We would have "Read - Videos, subtitles" and "Read and write - Images", plus possibly "Unknown files" in both cases. This would add height to the dialog box.

Hmm. That is tricky. I'm not used to thinking about these sorts of things when it's both "Too touch-oriented to just use less padding or have an always-visible scrollbar" and "Too security-critical to let people potentially overlook that we're using a scrollable pane to handle overflow".

Maybe, instead of grouping them under "Read" and "Read and write" headers, have an icon on each row which can indicate "Read-only", "Read-Write", or "Mixed" and users can tap the row to get details on which formats are being granted which permissions? Your proposed information sub-dialogs have a lot more unused height budget to spare.

(Perhaps an eye, a pen/pencil, or an icon combining both.)

...assuming it's necessary to indicate "Mixed" at all at the top level. Just distinguishing "this group contains only read-only entries" from "this group contains at least one write-granting entry" may be enough.

Also, if anyone is concerned about not granting write access to files - only granting read access, we need something to handle that, or we assume the user must give access to what is offered. What do you think?

I think it'd depend on how likely it is for an application to not be coded to handle unexpected "read-only filesystem" errors and crash as a result.

However, if you do support that, maybe make the info sub-dialogs contain a table of formats with "Extension", "Eye Icon", and "Pen Icon" columns where there's a checkbox/slider-switch widget in each cell in the latter two columns whenever such a permission was requested and turning off the eye icon switch visibly disables (i.e. greys out) the pen icon switch in the same row.

[Mikenux]

Very good idea, I will try!

I think it'd depend on how likely it is for an application to not be coded to handle unexpected "read-only filesystem" errors and crash as a result.

Yes, I will do for this case separately. Maybe it's more for the future.

[Mikenux]

Eventually I decided to use text to indicate permissions (more meaningful) and simple permission management (i.e. accept what's offered or go read-only):

[ssokolow]

The main dialog looks pretty good, so, for that, I'll mainly be focusing on areas where the phrasing could be tweaked slightly:

• "Access neigboring files and folders?" feels a bit odd to me as an isolated dialog, rather than a section in some larger prompting UI, but I'll need to think about how best to revise it.

• I recommend removing the terminal periods from the "Read." lines in the permissions list and looking into tweaking the "Read and Write, ..." lines. There's an aesthetic distinction between full sentences and short labels, similar to how you wouldn't put a period at the end of each entry in a tag cloud or in the label inside a pushbutton.

• "could impede app functioning" feels a little odd. The most in-line-with-professional-UI-copy way I know to phrase it would be "may impede app function"

• "Read only", on its own, feels like something you'd be able to uncheck to force-grant write permissions where they haven't been requested. Even if that's not how a human would take it, it feels like something to be improved. Maybe something like "Deny write access" which makes it more clear that it's acting to veto a request, rather than to directly set the final value.

  "Force read-only access" would probably be the ideal phrasing if you can find an aesthetically pleasing way to fit "may impede app function" on the line below. (Perhaps with similar "smaller and lighter" styling to what was used for the "Read and Write, see info for details."

As for the popup menu on Always, I'm a bit dumbstruck, because it's so flat and free of interaction cues that it reminds me of a web app where one of the CSS files failed to load. The following isn't meant to be an attack on you, but a barely-filtered stream-of-consciousness representation of my reaction:

• Is "Always for Vidim Viewer" a heading or a default/selected element in a list?
• Why is it centered while the ones below it are left-aligned?
• Why are there no visual cues that this is anything more than a rich-text click-to-close tooltip?
• Ignoring the content in them for a moment as a human would parse it, are the lower two lines one widget or two?
• With the rest of the UI so defined by mobile UI/UX influences, why does this feel like a UI where you have to rely on the on-hover highlights and cursor changes to understand how to interact with it?

[Mikenux]

"Access neigboring files and folders?" feels a bit odd to me as an isolated dialog, rather than a section in some larger prompting UI, but I'll need to think about how best to revise it.

It's inspired by what GNOME does, like "Save changes?". What's odd for you?

I recommend removing the terminal periods from the "Read." lines in the permissions list and looking into tweaking the "Read and Write, ..." lines. There's an aesthetic distinction between full sentences and short labels, similar to how you wouldn't put a period at the end of each entry in a tag cloud or in the label inside a pushbutton.

Sure. For "Read and Write": "Read and Write − Limited..."?

"could impede app functioning" feels a little odd. The most in-line-with-professional-UI-copy way I know to phrase it would be "may impede app function"

Okay.

"Read Only"...

In the current file selector, it's "Open files as read-only". Note that it is unchecked by default (if that is the problem). So, can we keep as is (or "Read-only access"), or should I go for "Force"?

Perhaps with similar "smaller and lighter" styling to what was used for the "Read and Write, see info for details."

Next to it or below?

As for the popup menu on Always, I'm a bit dumbstruck, because it's so flat and free of interaction cues that it reminds me of a web app where one of the CSS files failed to load. The following isn't meant to be an attack on you, but a barely-filtered stream-of-consciousness representation of my reaction:"

I completely agree with you (I was expecting this kind of reaction). I didn't polish it. I need to find the best interface because it's unusual to have something like "phrases" acting like buttons. "Always for Vidim Viewer" is indeed a title. Do you agree with the wording (including the title)?

[ssokolow]

It's inspired by what GNOME does, like "Save changes?". What's odd for you?

That's what I need to think about. I think it's too late in the evening for me to reverse-engineer what my intuition is picking up on... but I'll make an initial attempt.

I think it's that "Save changes?" is implicitly short for "Do you want to save changes?" while "Do you want to access neighboring files and folders?" isn't quite correct. (It's not prompting whether you want to access them now. It's prompting to grant permission for the application to access them at a later time of its choosing.)

Sure. For "Read and Write": "Read and Write − Limited..."?

I'm not sure if the punctuation in the middle needs to change. The important thing is that it should be consistent with "Read", which looks wrong with a trailing period, so it shouldn't have a trailing period either. I'll try to remember what the conventions are for that comma after I've slept.

(This is the kind of thing that I originally learned from HIGs and other similar UI design guideline documents in the 90s. Does the GNOME HIG have anything to say on punctuation in these circumstances or is it something they haven't realized still needs to be taught in the 2020s?)

In the current file selector, it's "Open files as read-only". Note that it is unchecked by default (if that is the problem). So, can we keep as is (or "Read-only access"), or should I go for "Force"?

The important part is to communicate that you're overriding/vetoing the requested permissions. A word like "Deny" or "Force" helps to convey that distinction. "Open files as read-only" is still a bit weak on that front.

Next to it or below?

Below. My primary concern is that choosing good phrasing will make the line too long if you don't. The "smaller and lighter" is just an idea for how to improve the aesthetics and sense of structure when you do.

I completely agree with you (I was expecting this kind of reaction). I didn't polish it. I need to find the best interface because it's unusual to have something like "phrases" acting like buttons. "Always for Vidim Viewer" is indeed a title. Do you agree with the wording (including the title)?

I think having a title in a popup menu is inherently the wrong design. Generally, when a platform supports them (and some don't), they're used purely as section headers... to give separators titles.

However, I'm getting very sleepy very quickly, so I'll have to finish replying on this point tomorrow.

[Mikenux]

I will check out the GNOME HIG.

Regarding the "Always" button, I think the best is to remove its options. Initially, the goal was to inform the user so that they could make a decision. That is, if the user trusts the app, they can click Always. Also, I don't understand the meaning of always granting access to a specific folder vs. all folders, because we want to grant an application access to files adjacent to a file we open, not a folder . Why should I grant access to the parent folder (in which I opened a file)? Why would I give this access to some folders and not others (if I want the app to just work)?

I think to not complicate things too much, the solution we have is better than just having access to all files and subfolders:

• Limited access to specific files and folders (and files within folders).
• Give information to the user about what the application can do, which files and folders an application wants to access and the permissions on this access.

Maybe in the future we could add a confidence index to help the user decide whether to click "This time" or "Always". For write access, I'm thinking of a "Write" portal (but that may require application changes).

[ssokolow]

Regarding the "Always" button, I think the best is to remove its options. Initially, the goal was to inform the user so that they could make a decision. That is, if the user trusts the app, they can click Always. Also, I don't understand the meaning of always granting access to a specific folder vs. all folders, because we want to grant an application access to files adjacent to a file we open, not a folder . Why should I grant access to the parent folder (in which I opened a file)? Why would I give this access to some folders and not others (if I want the app to just work)?

To be honest, I was sort of thinking that too... I'd just gotten into my head that you were wedded to having the choice for some reason.

My original conception of this feature was more of an on-install/on-first-run thing where it wouldn't be possible to prompt per-folder.

That said, there's still the question of how to undo choosing "Read only + Always".

For write access, I'm thinking of a "Write" portal (but that may require application changes).

That's the problem. Even as an author of new stuff, I prefer not to go beyond what PyQt exposes if at all possible, because I want my creations to be portable and I don't have time to babysit special code-paths for each platform when there's a portable abstraction. If that means resorting to manifest-defined permissions grants, so be it. (eg. I'll consider altering my designs to employ a QSystemTrayIcon, just so I have a portable way to emit notification popups without adding a direct, platform-specific dependency on D-Bus.)

(Bear in mind that anything using SQLite as its on-disk file format is almost certainly going to need write permission, since it uses a separate file for its journal in modes like the more performant WAL mode that's pretty much only not the default because of their policy on backwards compatibility.)

If we're having this dialog, then my compromise between security and uptake by developers/maintainers would be to declare these rules in the manifest, and then have this dialog presented to the user the first time they become relevant, similar to the direction various mobile app and browser extension permissions systems are going.

(See, for example, the "Permissions" panel on the addons.mozilla.org page for Sidebery.)

[Mikenux]

That said, there's still the question of how to undo choosing "Read only + Always".

I just know there's this option in the file picker (not sure if it's something that's present for all apps or just apps that support it).

Because this option is in the file picker, maybe having something like a message in the dialog saying that this option has been checked, that there will be no write access, and the user must click cancel if they want write access (this takes the user back to the file picker)? While I think having "Open files read-only" in the file picker does not make much sense to users, I think a message would definitely be the best option given what we have right now.

That's the problem. Even as an author of new stuff, I prefer not to go beyond what PyQt exposes if at all possible, because I want my creations to be portable and I don't have time to babysit special code-paths for each platform when there's a portable abstraction. If that means resorting to manifest-defined permissions grants, so be it. (eg. I'll consider altering my designs to employ a QSystemTrayIcon, just so I have a portable way to emit notification popups without adding a direct, platform-specific dependency on D-Bus.)

Sure. I'm thinking of exposing my user view on that. It is better to start a discussion as soon as possible than to do nothing. Maybe we can have different solutions. If a trust index is to be developed, something clearly needs to be done to not penalize developers (i.e. prevent users from avoiding using their apps) who cannot update their apps to support stuff that requires application changes. Also, isn't it possible for toolkits to have a portable abstraction that can use different platform backends?

In the end, let's stay on an incremental approach towards full sandboxing.

[ssokolow]

I just know there's this option in the file picker (not sure if it's something that's present for all apps or just apps that support it).

Adding a "Read only" checkbox to the file chooser dialog would be a good way to do it as a one-time thing, but it would have the wrong UX for persistent changes.

If you can coordinate it to ensure that all the XDG portal hosts support it (bear in mind that Kubuntu 20.04 LTS is still stuck on a KDE portal host where requesting a directory picker produces a file picker that refuses to let you select anything and the PPA only provides updated versions of the GTK portal host), maybe some kind of Preferences button, similar to how you can edit the Places sidebar preferences from inside a KDE Open/Save dialog.

(That said, integration on that in Kubuntu 20.04 LTS isn't ideal. It's very annoying to see the checkbox for my favourite "not even Windows has this" feature say "Only show when using this application (xdg-desktop-portal-kde)" and one of the reasons I tend to only use Flatpak for KDE applications available through Flathub if they're things I use infrequently, like the Okteta hex editor. It's bad enough that Places bookmarks I only ever use for Firefox have to be visible in all applications.)

Otherwise, maybe coordinate so each XDG portal host frontend provides a control panel that serves a similar role to Flatseal and shows up in the desktop's settings app. (i.e. For the KDE frontend, it'd be a KCM rather than a standalone application.) I'd like that anyway, as a means to revoke the persistent grants the File Chooser Portal already supports.

Because this option is in the file picker, maybe having something like a message in the dialog saying that this option has been checked, that there will be no write access, and the user must click cancel if they want write access (this takes the user back to the file picker)?

You're talking to a KDE user who, prior to upgrading from Kubuntu 16.04 LTS to 20.04 LTS, disabled Chromium's KDE Open/Save dialog integration, despite disliking GTK's Open/Save dialog, because shelling out to kdialog --getsavefilename added 0.3 to 1.0 seconds on every Ctrl+S when trying to batch-save and close a bunch of middle-clicked image tabs. (Plus, in that era, the KDE chooser had a bug which made keyboard-only interaction less polished than GTK's file picker.)

Adding a whole new dialog to the flow every time, even if only for situations where read-only was forced, is unacceptable and would prompt me to break out Flatseal and loosen the security restrictions. As a general UI design principle, adding friction to the common case is a very hard thing to justify.

Also, isn't it possible for toolkits to have a portable abstraction that can use different platform backends?

Definitely, but whether you can achieve that kind of cooperation with GTK and Qt developers is the question. It's never a good idea to make plans based on assuming that sort of thing.

[Mikenux]

"Open files as read-only" is an option already present in the gtk side file picker. I didn't know it didn't exist on the KDE side. Also, I don't use old versions. Also, is flatpak well supported on Ubuntu and its derivatives (because Ubuntu supports snaps)? Keep in mind that better support may be present in recent versions of the operating system, desktop environment, and/or flatpak.

Having something to manage permissions is nice, although I'd prefer a solution for not managing things, but that's up to desktop environments (but you'll definitely need to use a recent version) or to someone to develop an independent application like Flatseal.

Now the read-only option is unchecked if a file is selected in the file picker. However, the file picker is not there if you open a file directly from a file manager (I just thought of it while writing this comment). So the easiest solution is to have this neighboring files dialog incompatible with this read-only checkbox. Another solution is to not have this dialog, but to have a checkbox as mentioned in the first post of this issue (but we will lose the fact of notifying the user and I don't know if such checkbox in the file picker makes sense to a user).

Definitely, but whether you can achieve that kind of cooperation with GTK and Qt developers is the question. It's never a good idea to make plans based on assuming that sort of thing.

Different plans can be made (the different solutions). If having cooperation between GTK and Qt developers is necessary, GTK and Qt developers should know what to work on...

[ssokolow]

Also, I don't use old versions.

Until a few days ago, 20.04 LTS was the newest version available in a *buntu Long-Term Support release (they roll a new one every two years) and I haven't had time to block out a day or two when I can fix things up if an upgrade breaks something. (I don't think I've ever not had to work around new bugs introduced by a distro upgrade and, usually, upgrading rather than doing a full reinstall causes more. That's why I use an LTS distro and let Flatpak provide anything I need to keep more up-to-date.)

Also, is flatpak well supported on Ubuntu and its derivatives (because Ubuntu supports snaps)?

Ubuntu follows the Debian convention of, aside from security patches, freezing the versions at whatever they were when they release was made.

The only reason I can install certain things off Flathub is that the PPA provides updated versions of the core Flatpak components needed to satisfy the "requires minimum Flatpak version" field in their manifests.

As for snaps, I hate snappy's "forest of mount-cluttering loopback mounts pointing at slow-to-load squashfs images" architecture and Steam-like "you'll update when we say" design, so I rip it out and borrow Linux Mint's APT config for blacklisting it from being pulled back in by Canonical's decision to make certain things (eg. Chromium) into dummy packages which reinstall snappy and then install the requested application via snappy.

Having something to manage permissions is nice, although I'd prefer a solution for not managing things, but that's up to desktop environments (but you'll definitely need to use a recent version) or to someone to develop an independent application like Flatseal.

I'd argue that, if your system provides a mechanism for setting something persistently (like the File Chooser Portal's support for persistent grants), then it's your responsibility to provide a well-documented way to change those settings at any point in the future... especially if it doesn't provide any kind of warning that they will be persistent.

I almost panicked when I learned that File Chooser Portal grants could be persistent, and googled for ages trying to figure out how that worked before finally getting told about it in a GitHub issue as a tangent to something else. (There's a data store that's apparently currently only possible to manipulate by crafting raw D-Bus calls.)

So the easiest solution is to have this neighboring files dialog incompatible with this read-only checkbox. Another solution is to not have this dialog, but to have a checkbox as mentioned in the first post of this issue (but we will lose the fact of notifying the user and I don't know if such checkbox in the file picker makes sense to a user).

Maybe keep the dialog and make it an on-first-use sort of thing like in mobile apps and browser extensions, but require that, if a desktop wants to support "force read-only" operation, they have to build it into their file-picker dialog.

Different plans can be made (the different solutions). If having cooperation between GTK and Qt developers is necessary, GTK and Qt developers should know what to work on...

Coming with a proposal is fine... you just don't want to try to dictate terms to people who have enough clout to say "Sorry, we don't like that. Sad day for you."

[Mikenux]

I'd argue that, if your system provides a mechanism for setting something persistently (like the File Chooser Portal's support for persistent grants), then it's your responsibility to provide a well-documented way to change those settings at any point in the future... especially if it doesn't provide any kind of warning that they will be persistent.

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

Coming with a proposal is fine... you just don't want to try to dictate terms to people who have enough clout to say "Sorry, we don't like that. Sad day 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.

Maybe keep the dialog and make it an on-first-use sort of thing like in mobile apps and browser extensions, but require that, if a desktop wants to support "force read-only" operation, they have to build it into their file-picker dialog.

Perhaps. It is easy to adapt. Remember that the flatpak developers have to decide. The basic design is there.

[Mikenux]

Maybe keep the dialog and make it an on-first-use sort of thing like in mobile apps and browser extensions, but require that, if a desktop wants to support "force read-only" operation, they have to build it into their file-picker dialog.

Perhaps. It is easy to adapt. Remember that the flatpak developers have to decide. The basic design is there.

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.