Ho-hum. I can understand the appeal of that idea, but in practice quite a few file formats and applications rely on implicit and/or file-format-specific relationships between multiple files. I.e. I as the user pick one file for opening, but in order to successfully carry out that task, the program actually needs to access quite a few more additional files based on the initially opened file.

None of the sandboxing approaches I've seen so far has a really great story for that usecase.

AFAIK Android and Windows don't offer anything in that regard, no idea about Flatpak, and Apple at least seems to handle related files with differing file extensions, like movie.mp4 and movie.srt, but would still break down for more complex file formats where related/associated files don't share the same file name sans extension.

Plus it means you always have to go through the official OS file dialogues and can't e.g. just manually edit a path directly in the app's UI if that would be more convenient…

An example of such a thing, that is related to this thread, is the X11 socket being accessible even when the directory it appears to be contained in isn't bind mounted into the flakpak sandbox's mount namespace. This is because regular file system permissions do not apply to abstract sockets (which X11 can and does listen with).

I think unsharing the network namespace would fix this, and configuring X11 to not listen with any abstract sockets might be possible, but this is just one of many examples of trivial sandbox escapes that most people would never even consider.

The best bet to isolate untrusted software is to run it under a different UID (less safe) or inside of a VM (probably very safe).