Okay, so I know Windows probably doesn't actually work this way, but from a user interface perspective... what's the rationale on giving an App permanent access to the user's home folder directories? Don't most well behaved apps have a file open / folder open dialog, which should be able to grant access to files at runtime? If the file opening dialog is provided and controlled by the operating system (I realize many, many legacy apps work differently in Windows) then the OS can silently grant permissions at the time of open, rather than letting apps either have free reign or no access at all.
I feel like this is the expected behavior anyway; Power Users may run utilities that need to touch the whole system, but most regular users are doing pretty good to juggle more than a handful of open files in their mental model of the machine while they're using it. The idea of file permissions is already pretty foreign to the average end user. Applications already have a designated area (%APPDATA%) where they can store their temporary files and things, so perhaps the documents folders should be more locked down by default.
The main problem and is that the file open dialogue generally runs in the app's memory space, at which point we can't stop the app corrupting it in any way it likes.
I hope we are moving to a world where apps are built of seperate processes, most of which have minimal access. If nothing else, this will make many old buggy C libraries (including code I have written) much less dangerous.
What the parent comment (and some siblings) are saying is that the file open dialog's behavior can probably be modified by the application that calls it, e.g. faking the effect of the user clicking Open on every single file.
That could maybe be prevented by keeping the relevant sections of memory marked as read-only, and maybe it already is.
Heck, most CLI tools keep credentials in text files which are very easily read by random apps. Sometimes people will keep all a bunch of API keys in a single .bashrc file, which gets passed down to every child.
On macOS I've been experimenting with creating a separate keychain for storing most of my API keys. Once keys are stored securely, you can write a wrapper for each tool. The wrapper just has to read the value from the keychain and call the original. That way you lower the changes of keys being needlessly shared. It has good UX too, since it only has to prompt you when it's first used. Although for that to really work I think you have to sign the wrapper, otherwise anyone can just edit it.
It's unfortunate that Windows seems to conflate sandboxing applications and central control of which applications are available. I'd love all the apps on my system to be sandboxed, but not if I lose the ability to install "unapproved" apps at the same time.
It originally did, but doesn't anymore. Version 1607 last year both added the ability to double-click install modern (sandboxed) apps outside the store and for the store to carry desktop apps, so that there's no longer any necessary correlation between sandboxedness and storeness. (personally I'm not sure this is entirely a good thing TBH)
The best protection against malware / ransomware, hardware failures or stupid accidents of your own doing is provided by regular backups, not by app store restrictions that don't work anyway for the stated purpose.
I do not have SELinux/AppArmor installed, I can't remember the last time I installed an antivirus and it doesn't matter, because I have backups with file versioning going back for a whole year of everything important.
My laptop could burn in a fire right now and I wouldn't lose anything.
But then I don't remember the last time I had problems with malware, because I don't install random software from shady internet sources either.
It's typical of software developers to solve social problems by automation instead of education. It doesn't work well, it never did.
This is one of the "common dialogs", and as mentioned elsewhere it runs in the app's memory space so you can, if determined enough, mess about with them. They also run all your shell extensions, which is a fun place to put malicious code.
What might be viable is UAC-style privilege requesting to get out of a sandbox, but that kind of thing was really unpopular when UAC was introduced with Vista.
this is essentially how the sandbox works on macos from what I understand. 90% of applications should work fine for this. Some though like antivirus (as an example) can't really do so.
Reality is that almost all applications do not use sandbox, unless they are forced too. At least in my experience. I have 16 installed apps and only 2 from AppStore. Check out Android. It has very fine-grained permissions model. But most developers don't care and ask a lot of permissions even for simplest apps. It turns out that users don't care too. I'm not sure how it works for iPhone, where App requests access to some specific very privacy-related functionality, like location or address book, but I think that even on iPhone most users will press "Yes" without second thinking or even careful reading.
I feel like this is the expected behavior anyway; Power Users may run utilities that need to touch the whole system, but most regular users are doing pretty good to juggle more than a handful of open files in their mental model of the machine while they're using it. The idea of file permissions is already pretty foreign to the average end user. Applications already have a designated area (%APPDATA%) where they can store their temporary files and things, so perhaps the documents folders should be more locked down by default.