Application Sandboxing is a feature of ACS that limits the environments in which certain code can execute. In other words, it means running a process in a Job that limits its ability to interact with other processes, as well as some specific types of interactions with the operating system, such as:
- Reading or writing from the clipboard
- Shutting down the system
- Adjusting display settings
application management (MAM) that limits the environments in which certain code can execute. In the Windows world it primarily means running a process in a Job which limits its ability to interact with other processes.
To a large extent in the post-Windows Vista era, most of the benefits of cross-process protection are mitigated by the Integrity Level (IL) mechanisms introduced.
Some of the internet facing apps today (such as IE, Chrome, Word, Adobe Reader) already implement their own extended sandboxing. As such, this mechanism would not apply to them.
Further reading that Application Sandboxing in Windows can be found at:
http://www.chromium.org/developers/design-documents/sandbox
http://www.chromium.org/developers/design-documents/sandbox/Sandbox-FAQ
"Applications like IE and Chrome and I believe even Adobe actually create their own internal sandboxes that are completely locked down: Not only do they have the restricted ID, but actually remove the User’s ID etc. This is more in regards to the Chromium description of sandbox where they’re not even allowed to Write. They restrict the process so they’re not allowed to Write to the Windows and everything and they have their own API set to…in essence they can’t use the Windows API set and have to use a restricted API set that the Parent sets up to communicate back to a trusted process to do any user interaction or anything like that."
"You can place multiple apps in the same sandbox, but the process rights is another level of security on the sandbox."