FileChooser: add option to open file with or without write access
Needs ReviewPublic

Authored by jgrulich on Mar 23 2020, 11:16 AM.

Details

Reviewers
None
Group Reviewers
Plasma
VDG

Diff Detail

Repository
R838 Flatpak Support: KDE Portal for XDG Desktop
Branch
filechooser-readonly
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 24099
Build 24117: arc lint + arc unit
jgrulich created this revision.Mar 23 2020, 11:16 AM
Restricted Application added a project: Plasma. · View Herald TranscriptMar 23 2020, 11:16 AM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
jgrulich requested review of this revision.Mar 23 2020, 11:16 AM
apol added a subscriber: apol.Mar 23 2020, 12:08 PM

This is a feature we generally don't show. What's the use-case?

jgrulich added a comment.EditedMar 23 2020, 12:18 PM
In D28218#632843, @apol wrote:

This is a feature we generally don't show. What's the use-case?

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?

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.

but you can restrict the write access if you don't the sandboxed application to modify the file.

Under what circumstance would you want that?

but you can restrict the write access if you don't the sandboxed application to modify the file.

Under what circumstance would you want that?

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.

For the record, GTK file dialog has same option:

"Otevřít soubory pouze pro čtení" -> "Open files as read-only"

ngraham added a reviewer: VDG.Mar 23 2020, 4:47 PM

but you can restrict the write access if you don't the sandboxed application to modify the file.

Under what circumstance would you want that?

For example when using new, non-verified application, which you don't trust it won't modify the documents you are viewing?

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.

If there are objections to this change, we can just make all the opened files automatically writable.

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. :/