Running apps in a sandbox should be the default behaviour for any OS by now. No app should have the privileges to access any file by default, except for files that are either created or owned by that app & user.
Sharing files between apps should be done as an opt-in basis, with explicit permission by the user, either file-by-file or per group of files.
"Trivial file conversion" tool can be implemented the same. The app tells the OS "hey, I want some files to convert" and the OS either grants access to a set of files/folders, or queries the user which file(s) (s)he wants to provide. IE the "open file" modal is the only window to accessing files. You can think of it like the HTML5 File upload & Drag/drop APIs, but a bit extended & more user-friendly.
Obviously smart engineers can think this through for longer than 3 minutes like I just did, and come up with better/user friendlier/safer solutions. But it breaks all backwards compatibility in almost any desktop OS
Only my backup tool gets root and can access other application's data - random trash games I download or even if I were to install them from pirated sources are unable to do that.
It's a vast improvement at the very least, even if not a perfect one.
There should be some very good definition for "App". I expect xz(1) to to be able to read any file I give to it (% xz myfile).
I would however expect chromium to only modify stuff in ~/.config/chromium ~/Downloads and be able to read only the libs it needs in /lib. But what about if I need to render an HTML page that's in ~/git/my.blog/index.html?
OpenBSD did some great things with pledge(2)[0] but truly fine-grained control like SELinux, AppArmor have met only limited success because of how complex they are to setup.
[0] http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/...