The “Optional” file has the following declarations in it:
As you can see, it requests the ability to display “safe” windows (MessageBoxes and the like) and says that Execution is optional (and since Execution is always granted by RequestOptional, this basically means that nothing else is required).
The “Refuse” file has the following declarations in it:
As you can see, it requests the ability to display “safe” windows (MessageBoxes and the like) and says that it refuses to access the Environment, even if policy grants it that permission.
The main program then simply tries to run a handful of (identical) methods on an object from each assembly, some of which will demand specific permissions:
If you have done everything successfully, you should see that code using RequestOptional fails to run both the GetUserName method (which needs EnvironmentPermission) and the ReadFile method (which needs FileIOPermission), whilst the code using RequestRefuse only fails to run GetUserName because it explicitly refused EnvironmentPermission but was still granted FileIOPermission.
The “Optional” code is therefore less susceptible to luring attacks because it can’t do anything except execute and show MessageBox windows (even by accident), whereas the “Refuse” code could theoretically be tricked into doing anything other than accessing environment variables (yes, this is a very convoluted example 😉 ).