file chooser: explicitly say "the app will be given access to this file"

[smcv]

We seem to have this as a frequently asked question (I'm paraphrasing several user reports here):

I have a Flatpak app [which is compatible with the file chooser portal, but the user doesn't know that] and I gave it access to ~/Pictures. I can click on File -> Open... or File -> Save As... and select a file in ~/Documents. Is this a security vulnerability?

This is in fact not a vulnerability, and is the whole point of having a file chooser portal - it's asking for user consent to give the app access to the selected file, as a side-effect of asking the user which file they want - but that's not always obvious to users.

Can we stop this being reported quite so frequently by adding a line of text to the bottom of the file chooser window, maybe something like this?

The app "Recipes" will be given read/write access to the selected file.

That would also make sure the user is given the opportunity to make an informed decision.

I'm reporting this against -gtk in its role as the reference implementation of a file chooser, but all of the file chooser implementations (-gnome, -kde, -xapp?, etc.) should have behaviour similar to -gtk unless their authors are willing to deal with the support burden of being different.

A side benefit of this would be making it a bit more obvious whether an app is using sandbox-friendly file choosers that will go via the portal, or its own non-sandbox-friendly file chooser that requires the app to be given static permissions (Flatpak --filesystem or whatever is Snap's equivalent).

[smcv]

See also flatpak/xdg-desktop-portal#995, flatpak/flatpak#5391, flatpak/flatpak#3977, flatpak/flatpak#5028, probably others.

This would also make it more obvious that the file chooser is giving access to the selected file forever, not just this one time (see also flatpak/flatpak#4758).

[swick]

I've also found it not obvious sometimes that you're giving access to an entire folder to the app and if we want to let apps access neighboring files this issue becomes very pressing.

One possibility is to split the filechoosing process into two parts, one where the user select something and then one where the filechooser tells the user what files and folders will be shared with the app.

I made a mockup of that flatpak/xdg-desktop-portal#463 (comment) where the 2nd part gets skipped when only a single file is shared but maybe it should be the two parts always.

Either way, this is a design question and should probably made into an issue here: https://gitlab.gnome.org/Teams/Design/os-mockups

[smcv]

Either way, this is a design question and should probably made into an issue here: https://gitlab.gnome.org/Teams/Design/os-mockups

Good idea, opened https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/221.

I made a mockup of that flatpak/xdg-desktop-portal#463 (comment) where the 2nd part gets skipped when only a single file is shared but maybe it should be the two parts always.

I'd personally prefer to add a footer to a single-step dialog instead of annoying users with a second step, at least in the simple cases like "open one file", but I'm not a UI/UX designer.

The second step is probably a necessary evil in situations where it isn't easy to describe what will be opened in a concise way, but I'd personally prefer to only have it when it's really necessary.

[smcv]

if we want to let apps access neighboring files this issue becomes very pressing

I think that feature request would be a good thing to have, but it's also rather complicated, and I don't want to let it block simple improvements like making it a little more obvious that "the system" is going to be doing something to give access to the app.

[Mikenux]

This would also make it more obvious that the file chooser is giving access to the selected file forever, not just this one time (see also flatpak/flatpak#4758).

I am confused here. Are you saying that when we select a file in the file picker (portal version), the application "remembers" the access even when it is closed (that is, the next time the application will open, it will be able to access this file again without the user's consent)? In the problem you linked, it seems to be about giving access to a file in a folder that the app can't touch (I guess it's about the app can't delete any files in that folder, for example) - which will be to clarify that the application cannot do anything with the files in the folder, except the selected file. Could you clarify? Thanks!

[smcv]

Are you saying that when we select a file in the file picker (portal version), the application "remembers" the access even when it is closed (that is, the next time the application will open, it will be able to access this file again without the user's consent)?

It isn't the application that is responsible for remembering this, but otherwise yes. When you select a file in the file chooser portal, the portal uses GrantPermssions (or one of the shortcut methods that adds a document and immediately grants permissions on it) to record in the permissions store that the application has been given access.

You can see this in flatpak documents --columns=all: run it, then load a previously inaccessible file into some sandboxed app (GNOME Recipes is my usual test app, and uses the file chooser if you load a picture for a recipe), then run it again.

I wouldn't characterize this as "without the user's consent" because the entire point of the portal is to provide a way for the user to indicate what they want the app to have access to, but the reason I opened this issue is to try to make it obvious what the user is saying "yes" to.

In the problem you linked

I linked at least 6 issues, so you'll have to be more specific.

[Mikenux]

@smcv : Thanks. I'm talking about the issue of your comment I quoted: flatpak/flatpak#4758.

[smcv]

I replied to flatpak/flatpak#4758 to clarify. The short version is:

the next time the application will open, it will be able to access this file again

Yes, true. This means it is not "one-time" file access like the title of 4758 asked for...

the application cannot do anything with the files in the folder, except the selected file

... but this is also true, so it is access to a single file, and not to the rest of the adjacent files, which (IMO) is the more important part of what 4758 asked for.

[Mikenux]

For issues regarding the 'filesystem' permission, this is confusion as to what it does. For this, clarifying the documentation and information in Flatseal and the app stores seems to be the solution rather than having a sentence in the file chooser.

For issue flatpak/flatpak#4758, I saw that you assumed that this issue might be about "filesystem" permission, which it certainly the case. When the file chooser is used, I think it's clear that if I select a file, only access to that file will be granted. I wouldn't put a sentence to mean that. However, I agree that it's probably necessary to recognize that a file chooser uses the portal/flatpak, which can also be done for any other portal that has a user interface.

Also, I opened flatpak/xdg-desktop-portal#808 where it is to open files as read-only by default and manage write permission. I think that makes sense. If you think this is useful, then I recommend not adding any sentence about read or write access, because if explicit write access is implemented, then users might wonder why there is no more sentences. That said, this would already be the case for the open files as read-only checkbox, but no need to add more. Giving appropriate information in the app stores (e.g. badges in GNOME software and their description) is an idea, as it can be updated if something changes.

As for permanent file access, I explained something about read-only access in flatpak/xdg-desktop-portal#808, without being really convincing . For the concept, permanent read access should only be granted in relevant cases such as libraries (for folders) and session restore (e.g. editing multiple documents). In such cases, something in the file chooser could then be done. Moreover, if write access is also concerned, the problem is that the app can still write to the files if a user, for example, closes a tab containing a document or at the next launch of the app. Information in app stores can certainly do the trick here too. I don't really know what the reality is, so if I'm wrong here, then that's fine.

[smcv]

When the file chooser is used, I think it's clear that if I select a file, only access to that file will be granted.

As one of the people who receives Flatpak bug reports and flatpak-security@ emails, I can assure you that, no, it is not obvious to everyone, and there have been several people who thought they had found a security vulnerability.

[Mikenux]

It's just that in the issues you've linked it's more about misinterpreting the filesystem permission than having issues with the file chooser, because the people affected by these issues change the permissions or just see them in Flatseal (flatpak/flatpak#5391). So clarifying in the file chooser doesn't seem to be the solution to fix these issues. Regarding the e-mails you receive, I cannot read them, therefore cannot interpret them.

Anyway, I'm all for having something to recognize that the file chooser offers some protection (a reminder that the user is using a sandboxed app, something they logically see when they install app), but I'd go for a badge (and clicking on it can display relevant information) rather than a sentence (for the reasons I mentioned).

[Mikenux]

@smcv:

I'm not sure what the "Open Files Read-Only" option in the file chooser is supposed to do: #433

So questions:

• Does "Open Files Read-Only" cause the app to explicitly ask the user for permission to write changes?
• If the app has permission to write, then what exactly can it do? Automatically change files? Automatically delete them?

Thanks!