To be fair, if firefox had the intelligence to know that it was being asked to attach a file it didn't have access to, it could prompt for a password. I don't expect full TRAMP like smarts from Emacs, but I don't see why this wouldn't be doable?

Granted, I'm viewing this as far easier than the sandbox "fake file system" approach? Firefox would be able to see the file exists, most likely, but just not have read rights to it. Yes, you can have some things it can't list, but I would expect that to be low on probability to want to attach to an email?

The Flatpak/XDG people are standardizing the concept of "portal"s for doing things that need help from outside the sandbox. A properly sandboxed Flatpak app can only open files bind-mounted for it via a portal call.

That's exactly my point. Users expect desktop software to read their home directory, which is an artefact of running under the same uid. The same can not be said for server software, where the expectation is different.

Linux desktop environments had the chance to set a precedent here where software could for example have had a directory named after the application under the user's home, and use subuid to access files. That is simply an example, but would be a backwards compatible way to create a shared culture how Linux desktop software operate, and easen a transition where desktop software could be limited to "their" own directory.

Instead they squandered this chance by focusing all effort on moving dotfiles around (.config was such a waste of energy where we the heated debate could have been about something more useful, such as the above). Now we have Snap and Flatpak which both try to solve a culture problem (where we store our files) with technical solutions (bind mounts! modal gui:s! popup dialogs!). These will not improve the situation. In the best case it will train users to click "Yes" more, which we know not to help security.