Easy, show a pop-up informing the user that the application tried to access so and so file, and if this was intentional, please click allow and try again.

When the sandbox works as it should, the application has no idea that so and so file even exists.

The flatpak portals are trusted system components, that work outside the sandbox and can present some choosers, where the user picks what will eventually become accessible inside sandbox, if the user agrees (whether files via file choosers, microphones, cameras, desktop sharing, whatever). The sandboxed processes talks to the these portal via IPC (dbus, normally).

The thing is, that outside of standard gtk3 and qt5 apps, nothing else uses portals yet (and gtk3 with qt5 do that at framework level, so it's transparent for the apps). You cannot sandbox random electron app, for example, and expect that it will work just like it worked when it was installed via deb or rpm. And with files, it is just not single files (document apps are relatively easy), but imagine opening project file inside IDE or playlist inside media player: the project or playlist was picked by the user and can be opened by the app, but it contains references to other files, potentially hundreds of them. Can you imagine asking the user to confirm opening each and every one of the hundreds of files?

And then there were people complaining that their locally installed SDKs cannot be used from sandboxed IDEs. Sigh, that's kind of the point...

Perhaps make it an optional setting?

"Enhanced Sandboxing (Warning: This feature is experimental, and may cause issues for some apps.)" or something of the sort.

It is... you can add/remove any paths you like. The default errs into what users are used to.

See also threads bellow; people complaining that the Signal client can save only into ~/Downloads.

Makes sense. I use flatpaks only very lightly, I apologize for not checking before opening my mouth :)

Opening the mouth is fine, nobody has fallen from the sky fully learned about everything ;).

If you learned something that is interesting or useful to you, then great.

Users are stupid, but they are not as stupid to press no on a request to allow an application to open files and then complain that no files exist.

As an counterargument, see all the comments to this article.

Most people here comment on something they have exactly zero idea about how the security model works, how the transition (i.e. holes in the sandbox and the reasoning behind them) works and what is the intended end-result (portals).

Imho not nearly the same thing.

Very similar. Either complaining about non problems, or complaining about some default they can change, or suggesting solutions that are over-complicated and simultaneously inadequate anyway.

Same underlying reason, except it is worse, because it is in the quadrant "they think they know, and they really don't".