> However, the new “more secure” Universal Windows Platform (UWP) sandboxes the file picker in a separate process, allowing neat features like capability-based access control. It returns a file handle which, if the selected file exists, will not overwrite the existing content!
That got me a bit worried, since desktop Linux is going somewhat in the same direction with sandboxed applications. So I did a quick search for the file chooser portal API, and if I understood what I found correctly (https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free... and https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free...), it does not return an already opened file handle; instead, the file is made available in a FUSE mountpoint within the sandbox (/run/user/$UID/doc/), and the call returns a URI pointing to that file. So, if I understood it correctly, developers can keep using the same traditional POSIX APIs they're already used to, with the same semantics they always had outside the sandbox.
That got me a bit worried, since desktop Linux is going somewhat in the same direction with sandboxed applications. So I did a quick search for the file chooser portal API, and if I understood what I found correctly (https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free... and https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free...), it does not return an already opened file handle; instead, the file is made available in a FUSE mountpoint within the sandbox (/run/user/$UID/doc/), and the call returns a URI pointing to that file. So, if I understood it correctly, developers can keep using the same traditional POSIX APIs they're already used to, with the same semantics they always had outside the sandbox.