While it is an ideal setup to lock everything down and while software used in business environments is content running in a restricted setup, there is a lot of home software still (games especially) that make it prohibitive to use restricted accounts. A few examples include:

- Game updates - often games will demand the ability to write to C:\Program Files and not actually store the game packages in the user's profile directory. On a truly locked down system, game updates would fall over due to permissions.

- Game DRM/"Anti-Cheat" - some DRM and "Anti-Cheat" engines require the ability to be able to administratively oversee the entire system process table as to prevent debuggers and memory dumpers from functioning. Many games with these systems will complain and refuse to run if they don't have enough privledges to get what they want.

- Many programs - a significant amount of programs used in home environments do not store things in the user's profile directory and instead insist on storing stuff in the program's install directory.

The problem is we're not living in an ideal world where you can simply lock accounts down and expect everything to play nice without your intervention and much of this falls on the shoulders of software vendors (their developers for largely being incompetent and the management for demanding DRM/Anti-Cheat engines).

In an office environment, it can be extremely easy to lock things down where software has been developed with restrictions in mind, not so much in a home environment unless you plan to reject a lot of software that your children may want.

This is an incorrect assertion, an assertion my previous post debunked, but I suppose I'll re-explain:

You could have a drive full of PDFs, you could have it full of PNGs, whatever file format you'd like. You could mount the drive as noexec, however when it comes down to it, a trusted program (NOT ON THAT DRIVE) can interact with those files and since file formats can be complex AND since the programs opening them are also complex, there's a chance that the program will be vulnerable to a crafted file that tricks the program to do something that a "regular movie" or whatever wouldn't do and may not have been tested for.

If you've written a file parser of any kind, you'll see how complicated it gets in having your program code check the file for abnormalities before interacting with it. This complexity is a steep curve and all it takes is not checking an array boundary for your program to mistakenly leak data memory into its executable memory space.

The old addage plays correct here: Never trust user inputs.