The Decision -
With the .Net Framework V2.0 release of ClickOnce, any ClickOnce App deployed from the internet zone can prompt the user for permission elevation.
For the earlier Beta2 release of ClickOnce, prompting had been explicitly disabled for internet applications that were not Authenticode signed. We consciously reversed this decision for the final release.
This decision of Microsoft has been questioned by a few in the ClickOnce/Security community. Though they do not agree with our decision, most of these blogs do try to be balanced and put forth both sides of the argument. However reading through a few community posts generated by these blogs, I did get a sense that there was a perception that this was a change pushed into the release by Microsoft at the last minute due to pressure from a few large customers.
I plan to articulate out here more clearly our thinking behind this change and hopefully debunk this perception.
The Thinking Behind It -
Non authenticode signed Internet ClickOnce applications were prevented from elevating in Beta2 with the primary goal to get user feedback on this decision so we could make a more informed decision for the final release.
The Beta2 feedback helped us realize that it was important to have a consisitent IE security model for Managed and UnManaged exes, diverging in the model was confusing and muddled our security messaging.
We also got a strong push to enable this scenario from hobbyist/non commercial/community/open source App developers who wanted to deploy their applications using ClickOnce but could not afford (both in terms of time and money) to get an Authenticode certificate.
Let's consider the scenario below ...
Jen is a .Net entusiast and a golf fanatic. She writes a .Net Golf Handicap calculator that unfortuantely needs Intranet (Not Internet) zone permissions to run. Jen wants to share this App on her homepage with her golfing friends and would also like them to get updates as she adds new functionality to her program; ClickOnce is the ideal choice of deployment technology for her.
If ClickOnce forced Jen to have an Authenticode certificate before she could share her App she would soon be looking at other deployment options. She could decide to just write the App in native code and share the exe. The native exe (even a Managed exe for that matter) would now be downloaded and run with Fulltrust on local machine, not a big security win.
Today instead Jen can use ClickOnce to downloaded her App and run in the Intranet sandbox. She also gets to keep her app current with ClickOnce and potentially push down required updates for issues she wants patched immediately.
If we flipped the scenario around to where Jen was the author of a malicious Addware App and wanted to prompt the user from the internet zone she can very easily do it today. ClickOnce has not opened up a new security hole here. We just extent the current IE security model. There are no default scenarios where you can cause a user prompt to come up using ClickOnce where you couldn't for unmanaged Exes.
Also there have been comparisions of ClickOnce with ActiveX in the past and the fact that unsigned ActiveX controls from the internet zone are now blocked by IE has been used as an argument for pushing for similar behavior in Clickonce. ClickOnce and ActiveX are naturally two totally independent technologies, but if parallels have to be drawn we see ourselves closer to exes than ActiveX, and hence as discussed above have tried to maintain the same security expereince that currently exists for exes.
Configuring Prompting -
The current ClickOnce prompting model is highly configurable.
Enterprises can also specifically disable prompting for particular zones or they can use the trusted publisher list to whitelist their ClickOnce applications to run without prompting and disable all prompting.
[MSDN - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwinforms/html/clickoncetrustpub.asp]