The document portal can mount a file to the sandbox either as read-only or with write access.
Edit: at this moment, when we open a file, it's opened as read-only and when you want to do some changes to it, you won't be able to. Either we can make all the files automatically writable, or we can make it as an option (as Flatpak devs intended). I can image some people actually using it in some cases for security reasons.
Hmm, this seems like the kind of nerdy exposing-implementation-details thing that would be problematic from a UX standpoint. I can see the use cases for wanting to open a read-only file read-write so you can actually save to it, but I think a better UX for this might be to ask the user right at the point of use, rather than putting a custom checkbox in the dialog.
And what's the use case for wanting to open a read-write file read-only?
Not sure if you understand what is this used for.
With this, you open a file with permission to read it or with permission to read and write to it. It maybe doesn't make sense to open files read-only outside sandbox, but for application with limited access users actually might use it. It doesn't make a read-only file writable (as I guess you think this is about), it just allows you to specify how you want the sandboxed application to work with the opened file. The GTK file dialog has same option. By default it opens files with read and write access, but you can restrict the write access if you don't the sandboxed application to modify the file.
For example when using new, non-verified application, which you don't trust it won't modify the documents you are viewing? I don't know, but the portal has the ability to restrict the permissions and I don't really see why this would be something wrong from UX point of view. Even the KFileWidget mentions exactly this use-case: https://api.kde.org/frameworks/kio/html/classKFileWidget.html#ace86a29da1c82ebdb54a8415d85cfbd7.
I wouldn't install an app I don't trust, and conversely, if I do trust an app enough to install it and launch it, I'll trust it with one of my documents.
But I guess I'm not really arguing against you or this patch, but rather this part of the Flatpak spec. I don't really think this option makes a lot of sense; if you really don't trust an app, then this isn't enough; you also don't want it to even read your documents! Who knows what it might extract from them and sent to a remote server? And if you do give it read-write permission but it messes up your document, what you need is a "restore" feature that will undo the untrustworthy app's vandalism of your document.
However I won't block this patch, since, as you point out, it's already in the GTK dialog and provided as an example in our own API docs. I just think there might be a more user-friendly and effective way of protecting our users' documents from untrustworthy apps.
Adding VDG for more comments.
Honestly that's what makes sense to me. I don't think the use case of "I trust this app enough to open it and show it my files, but not enough to let it modify my files" really exists. I think most normal users would just not use an app they don't trust, or not let it access their files at all, rather than letting it access their files for reading but not writing.
I'm not a security expert though, so maybe the above is hopelessly naive and dangerous. :/