Hi @review-team, users are often facing issues while opening files directly from their hard disk as expected. So, I think it’s better to autoconnect this plug.
https://github.com/johnfactotum/foliate/issues/1243
https://github.com/johnfactotum/foliate/issues/1153
Thank you <3
In addition they may also want to update the store page to suggest this, and maybe pin an issue at the top of their GitHub project, so they don’t keep getting bothered with questions.
As per the requirements on Process for aliases, auto-connections and tracks, foliate fits within the category of media viewers and would appear to be published by the upstream developer. So +1 from me for this request (although it will require the publisher to be vetted to confirm the association with upstream before this can be granted).
The upstream himself is the publisher, I’m just a collaborator. So, I’ll let john take up from here.
Hello. I’m the developer of Foliate. I’m not sure what it means to be vetted?
Based on the functionality of foliate snap, having removable-media interface connected should be expected from the users and makes sense. +1 from me as well.
I’ll pick up the publisher vetting process from here. @johnfactotum , I’ll shortly send you a private message, could you please respond to that? Thanks.
Looking a bit more into this, I still think it shouldn’t be necessary to require this interface. Couldn’t really find anything on this, but according to the comments in https://github.com/ubuntu/gnome-text-editor/pull/14, a Snap should be able to access files with the document portal, even when opening through a file manager. Is this the case?
If so, it would be better to not allow it to access removable media. The same applies for home. Or at least the permission should be read-only.
If not, it’s still debatable whether this is a good idea, as it’s punching a much larger than necessary hole to work around what is really a bug that should be fixed. It might be better to err on the safe side particularly when one could work around it by using the file chooser.
Portals will only work on systems that actually have them installed, on all other desktops (be it because users prefer a minimal WM-only install or they can not afford the disk space the portals require due to holding duplicate copies of files you access through them) the feature would then simply be broken… portals are nice, but have their drawbacks (and they will also only work when you invoke the app via GUI, something like foliate /media/$USER/books/mybookcollection will not work either)
The technique that @johnfactotum is talking about, i.e file-forwarding is actually a flatpak only feature and it probably works on older versions also, because it’s written in the desktop file of the app itself. Even I am not sure if desktop files for flatpaks are generated differently based on the flatpak binary version. But, yes they are using portals there. May be we can implement something similar here. Also @johnfactotum allowing removable-media doesn’t actually mean poking a hole in the sandbox. It’s actually protected by app-armor rules, and even though your if app is trying to do something malicious, may be trying to add a script in .bashrc or in any dotfile or dotfolder, apparmor restricts that. So, I would like to assure you that there is nothing to worry.
I would say that the fact that it isn’t allowed by default suggests that the risk is significant. For example, in older versions of Foliate, it was possible for a malicious e-book to read any local file and upload it online. It is true that it wouldn’t be able to read system files due to the sandbox, but as the documentation says, on the removable media, there are “potentially sensitive data such as photos, documents and encryption keys”.
I am unsure as a community maintainer, what should my stance be here? If upstream is only allowed. Then I think the team should drop this request.
As long as an apps feature set clearly points to using data on external media like a media player, ebook reader, office suite, etc and the app clearly mentions that it can access such media in its description, auto connection is usually granted… it would not be allowed “just for fun”, this is why it is requiring manual review.
The point of interfaces is that the user has full control and as long as she is informed about the fact that she can disable it should be enough
The risk with removable-media is those mount points can be literally anything. A good example would be that you might have other OS’s mounted there if you have a multi-OS setup on your machine. If we deny access to hidden files in $HOME for security, removable-media essentially gives access to the entire operating system of other OS’. For example a snap would be able to access the entireity of a Windows drive and manipulate it without restriction because Unix permissions wouldn’t apply to NTFS.
With the potential scope being that huge, this is why there’s vetting required, because the security becomes trust in the author should that connection be granted; the sandboxing itself is essentially turned off in a lot of potentially serious contexts.
The file managers would need to manipulate the portals directly to enable functionality like right clicking a file and using “Open With”. Otherwise you’d always be forced into using “File > Open” or similar, which can work but is a confusing UX.
Alternatively, experimental prompting support might be able to eliminate some of the UX friction by popping up a request, “[App] would like to access your external drives, please confirm if this is desired”; but currently that’s not near being production ready.
Well, in Foliate’s case there are really two different kinds of data access that it needs.
The 1st is the essential feature of media players and document viewers. Currently, with Flatpak, you can do this without giving it any filesystem access (I mean apart from the app’s own internal storage, etc.). The portal works even if you’re opening from the file manager.
Now the 2nd bit is a bit different. It’s usually why people think it’s necessary for “media library” apps to gain full home and removable media access. However, in Foliate’s case, the library is an optional feature, and even in this case, the feature still works using portals for as long as the file is persisted in the document store.
Anyway, my point is that, whatever is the case for 2, for 1, that is, for the case of file viewers, it should not be necessary to provide direct access to the filesystem. After all that is the whole reason why portals exist.
