CAS Part II
A better approach would have been to lock down locally running apps by default to a minimal set of permissions, say the default permissions of the Internet Zone minus the ability to connect to a server. This would would have been an unambiguous signal that the days of running untrusted applications is over but does raise the issue of how an application would be given the permissions it requires. One solution would be for Microsoft to provide a managed GUI Permission Manager component which could be invoked by an installer. The installer would supply full details of the components being installed and the permissions they require. The Permission Manager component would then ask the user whether they want to hand out these permissions and then configure the application if the users agrees. The installer could try to display a spoofed version of the Permission Manager component but this would not work because the installer would not have the permissions to configure the app.
This could become quite sophisticated. The installer could ask for different levels of permissions so that a more careful user could restrict more widely what the installed app could do. If the user did not grant the app sufficient permissions then every time the app is run it could invoke the Permission Manager component. In this way the user never has to launch a security tool: either the installer or the application itself launches the Permission Manager which means that whenever the Permission Manager runs it displays information specific to the application, i.e. the user never has to input anything about the app, only to respond to requests for permissions.
It seems a waste to have such a capable approach to Code Access Security and then not use it. Hopefully future versions of .NET and operating systems running .NET will take full advantage of CAS.