There was am academic system (whose name I unfortunately cannot recall now) which would hook up the "file open" dialog and run it from trusted mode. When a user would pick up a file, then the program would have access to it, and only it. This apparently worked pretty great for programs which needed only one file. It probably would not have worked as great for programs which do more advanced stuff, like IDEs which need to be able to "search in files". I think modern Androids can do the same sometimes?

But practically, as a person who runs sandboxed browser daily, it there is not "a great deal of convenience and restrictions". Even before sandbox, I'd download files to default location and later move some of them elsewhere -- so this is not really changing. A requirement to place files which need to be uploaded into a shared folder is somewhat annoying, but I found out that I don't upload that many files from browsers anyway.

AFAIK UWP does this.

> And still. If I can upload some text document or private picture with a web-browser onto some web host, then that web browser can also send that picture anywhere else to spy on me. Unless I need to give it permission every time I wish to do something such as that, which would be very cumbersome.

Now you are moving goalposts. Initially, you were discussing restrictions on the file system.

I concur that the current desktop security model is probably unfixable. All the tools to improve on it are here though. Android kinda solved it by restricting every app to its own assets and files by default. If the app needs more, it has to ask for permissions.

The problem with user approval for every single action is decision fatigue. It is already happening on Android: every app is asking for a ton of permissions. And it turns out that many of them are not granular enough. For example, Signal needs the numbers from the address book to find contacts, but nothing else. If I want that feature, I still have to give Signal access to the entire address book.