Domain permissions only apply to managed code hosted within the web browser.
All code in an application domain is restricted to permissions associated with the domain for purposes of code access security. In code access security, all callers up the stack must have the necessary permission to do an operation. Permissions are granted to application domains just as they are to code: in addition to all callers, the application domain must also have permission for a demand to succeed. In terms of the stack walk, the domain permissions are checked after the top of stack as reached (think of them as being at the “virtual top of stack”); overrides such as assert/deny may cause a demand to end prematurely, in which case domain permissions are not checked just as callers further up the stack may not be.
The most common case that illustrates the reason domains have permissions – in addition to code having them – is that of the web browser. A typical web page might have some text and graphics, script, and perhaps a control (like an ActiveX control). The web site of the page defines the application domain and through policy the permissions granted to it: usually web sites are not highly trusted so the permissions granted are modest and safe. The control, however, may already be installed on the machine and hence be given a higher level of trust than the web – most users trust code on their machine more than code on the web.
In our example when the script runs it gets permissions commensurate with being from the web, but the control gets higher permissions. When script calls the control the normal code access stack walk ensures that only operations allowed for the script’s lower permissions are possible: if script tries to make control do something it doesn’t have permissions for, the stack walk will see the script permissions and stop it. However, if the control runs at the top of the stack (not called by script) it has its full permissions intact: this is where the additional check of domain permissions knocks it down to the web site’s level of trust. This prevents a powerful control – that, say, displays and modifies private information – from running in the inappropriate context of an Internet site web page. While it may be argued that the control is running uninfluenced by web script and hence should get full rights, there are spoof attacks wherein the mere context of appearing in a web page is enough to confuse or trouble users so as to represent a problem. Note: it is possible for the control to assert permissions and potentially open up as security vulnerability that web pages could exploit (code access security depends on code only getting high levels of trust that do not have this sort of flaw).