Comment by oxylibrium | Hacker News Reader

Comment by oxylibrium | Hacker News Reader

Parent Full thread

Created an account just to reply to this - there is no "proprietary" API for actions like opening files.

Both Flatpak[0] and Snap[1] use the same xdg-desktop-portal spec[2], which covers stuff like opening files, taking screenshots, sharing screen, and sending e-mails, among other things.

The only major difference in the two sandboxing approaches (noted in [1]) is the ability to execute arbitrary code outside the sandbox - Snap requires you to disable the ("modern"?) sandbox and use "classic" confinement, whereas Flatpak has you send a command over D-Bus to `org.freedesktop.portal.Flatpak.Spawn` while still running the primary application in a sandbox.

This would only be relevant for a small number of programs like IDEs, which are, at the moment, a relatively poor fit for "application"-style sandboxes like Flatpak, or confined Snaps, IMO.

[0]: https://docs.flatpak.org/en/latest/basic-concepts.html#porta... [1]: https://snapcraft.io/docs/xdg-desktop-portals [2]: https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...

Thanks for a detailed reply and correction on the extent "proprietary APIs" apply (I hope my use of proprietary as in not-an-open-standard does not rub you the wrong way — perhaps "custom APIs" is better): I am happy to hear that it's at least a shared implementation between both for some, very limited things.

Even if I want to ignore the "exec()" differences, you are still limited to standard OS file selector (for instance no custom previews which is probably the most common thing apps customize): basically many apps will need to break backwards compatibility and move to a suboptimal solution (meaning expend effort for a worse UX) just to provide users with sandboxing.

Don't get me wrong, it would be great to get the best of both worlds, but since it means I have to trust individual app packagers to also provide security updates for each app, we are still a long way off from that best-of-both worlds.

(This explanation also adds some context to the recent Audacity release which mostly just moves all project files into a single file)

The upside of having the system draw file dialogs is that file dialogs from different apps look consistent, rather than getting out-of-place dialogs depending on what toolkit the app used. It might sound silly, but it's a real annoyance, and there are plenty of apps that don't implement any custom preview.

Oh sure, but it's hard to make a one-size-fits-all file chooser. The case in point: Gimp, not using GtkFileChooserNative, even though Gtk started off as the "Gimp ToolKit". Otherwise, Gimp does not get image previews.

Even if you do build support for previews in the file chooser, you lose the sandboxing since that preview-generating app now has access to any file a user simply previews. Unless you start introducing a separate, orthogonal previewing system, you also lose caching of generated thumbnails and such.

But it's not only previews: there's also the File-Roller (archive manager for GNOME) "Add File" file picker.

So, while it would be great to have consistent file choosers UX- and UI-wise, you'd be forcing some apps to do away with useful features. And suddenly, you are now into how much consistency matters in this particular case?

FWIW, some issues will remain forever (or well, a long time): in the days of gnome-vfs vs pure Gtk+ file choosers, one could give you non-local files [nfs, smb, sftp...], and the other couldn't, yet they looked exactly the same.

The same is true for Gtk file chooser today (local vs networked files), simply because some apps can handle them, and some can't. These UX issues always annoyed me more than the look of file choosers between apps.

In a sense, I am actually arguing for orthogonal, system-wide file chooser infrastructure with support for everything and your kitchen sink. These would now not be sand-boxed (I don't want to wait an hour for my gallery image previews to load, so caching FTW), so it's a big attack surface (all the previewers, with some like ghostview executing turing-complete PS programs), and it makes you question why would you need sandboxing for the rest of the stuff :)

Thumbnail rendering on GNOME is already sandboxed with bubblewrap, even when you're outside Flatpak: [0] for docs and [1] for code on how they accomplish it.

I don't think it's possible yet to ship thumbnailers in Flatpak - I'll try poking someone to see if there are plans for that.

[0]: https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/master/R... [1]: https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/master/l...

Reply on news.ycombinator.com