You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The underlying APIs (job control, app containers) allow sandboxes to be created without package identity or static declarations. It would be good to support a similar API for win32 app isolation, so that properly brokered silos can be created dynamically without reference to an AppxManifest.
Pitch
Sandboxing is a generally useful capability. The most widely deployed use of Win32's current sandboxing APIs is of course Chrome/Edge, which decides what the sandbox policies should be itself.
The current win32 isolation feature seems designed from a high-level-first perspective, in which it's assumed sandbox policies may be implemented by people who aren't the original app authors, hence the ACP tool and integration into MSIX. That's fine and a useful thing to have, but there are use cases where apps may want to set up sandboxes itself just like Chrome does. These will typically be obscure use cases that it's not worth addressing directly in Windows. Examples might be:
An app that downloads and executes sandboxed plugins. The capabilities might be fixed and should not be under the control of the plugin itself.
Command line apps. The capabilities might be worked out by looking at the command line flags, current working directory, etc.
Cases where the permissions UI needs to be customized.
If there is a Win32 or WinRT API to create and change capabilities of an app silo on the fly, this would enable many such use cases.
The text was updated successfully, but these errors were encountered:
Summary
The underlying APIs (job control, app containers) allow sandboxes to be created without package identity or static declarations. It would be good to support a similar API for win32 app isolation, so that properly brokered silos can be created dynamically without reference to an AppxManifest.
Pitch
Sandboxing is a generally useful capability. The most widely deployed use of Win32's current sandboxing APIs is of course Chrome/Edge, which decides what the sandbox policies should be itself.
The current win32 isolation feature seems designed from a high-level-first perspective, in which it's assumed sandbox policies may be implemented by people who aren't the original app authors, hence the ACP tool and integration into MSIX. That's fine and a useful thing to have, but there are use cases where apps may want to set up sandboxes itself just like Chrome does. These will typically be obscure use cases that it's not worth addressing directly in Windows. Examples might be:
If there is a Win32 or WinRT API to create and change capabilities of an app silo on the fly, this would enable many such use cases.
The text was updated successfully, but these errors were encountered: