ClickOnce and Permission Elevation
ClickOnce is a very cool client application delivery system that we shipped in V2.0 of the .NET Framework and that WPF (aka Avalon) makes use of as well. Before we even shipped V1.0 of the .NET Framework we have know that deployment is the key issue for client applications. No mater how good the UI framework is if the app can’t be deployed it is useless. While ClickOnce doesn’t solve all deployment (machine provisioning for example) it does make HUGE steps towards delivering web style deployment of client applications.
I really appreciate the feedback we have gotten recently on ClickOnce around Permission Elevation... One of the things a love about working on this technology is that we have such a great community that is active about telling us what they like and don’t like.
In response to the feedback, Saurab posted some more information about what went into our thinking around this decision... I’d love to hear your feedback and reaction... Just using his blog for comments is goodness or feel free to email me directly.
Comments
- Anonymous
February 28, 2006
Well, as a hobbyist whose been researching deployment options for his WinForms 2.0 application that he's been working on for a while, I investigated ClickOnce but decided that it's a non-starter for me. The problem is that ClickOnce doesn't work with Firefox or other non-IE browsers. In fact, at least according to what I read, it doesn't even work if a Firefox user uses IE to install the app, IE must be the DEFAULT browser for ClickOnce to work. Unacceptable. - Anonymous
February 28, 2006
I absolutely agree with Peter Golde. I was really exciting about ClickOnce. However, after realizing that it would only work with IE, I have lost that excitement. While I belive it has great potential, it is nearly useless for my projects and clients. It needs to be made browser-independent, whether that is IE, Firefox, Opera, or another. - Anonymous
February 28, 2006
Thanks PeterDono -- this is really good feedback, and we have heard it from others as well... say tuned.. - Anonymous
February 28, 2006
On the Java side they have had JNLP (similar to ClickOnce) for a while and it proved to be very successful in the deployment of a Pharmacy application (about 3000 stores) I worked on. Worked both in Firefox and IE. What I dont understand is that why does MS always bundle things up. They might be a technical explanation, but given the choice one has with regard to platforms and browsers nowadays, this should have been thought through. - Anonymous
February 28, 2006
The comment has been removed - Anonymous
February 28, 2006
(I posted this to the original but a few people encouraged me to post it here too).
Readers of Brad's blog probably are familiar with the idea of "the pit of success":
"The Pit of Success: in stark contrast to a summit, a peak, or a journey across a desert to find victory through many trials and surprises, we want our customers to simply fall into winning practices by using our platform and frameworks. To the extent that we make it easy to get into trouble we fail."
So now look at the scenario Saurabh describes. Jen is a .NET enthusiast, enthusiastic to get her software out the door. The path of least resistance (the pit) for Jen is to just specify FullTrust whether she needs it or not. You say "Today...Jen can use ClickOnce to downloaded her App and run in the Intranet sandbox." but this requires more work - Jen has to debug her app in the Intranet zone and do her best to figure out what permissions she needs. Your customers security depends on Jen going the extra mile here. Multiply by a million and once again you train your user base to click OK for everything, rather than seeing a need to press OK as unusual and risky. The pit leads to a less secure environment for everyone, especially my mother-in-law who will click "Yes" on any dialog whatsoever :)
Requiring Jen to get a certificate changes the dynamic. As you say, it's a pain for Jen to do that, so the path of least resistance is for Jen to do the right thing with CAS. Jen would learn better security habits and my grandmother would be a little safer. That is much better for your customers, even if it inconveniences Jen.
Your argument that following the ActiveX model will lead to wider adoption is specious at best. ActiveX has caused all kinds of problems for Microsoft's customers because one click gives the software carte-blanche on the machine. I think your community would prefer that you start to address this rather than continue down the same road that has brought a lot of the spyware problems to begin with.
Finally some anecdotal evidence. I have shown ClickOnce to hundreds of developers over the last year and a half (ever since the MAGEUI days). The audiences I saw were generally pleased when I showed them that ClickOnce refused to install unsigned code coming from the Internet zone. Now I always see some of them rolling their eyes and groaning when I show them this behavior. Several have asked me why I bothered showing them CAS at all if it can be subverted so easily. So I'm not sure the developer community is really that enthusiastic about this particular policy decision. - Anonymous
March 01, 2006
I believe ClickOnce is more suitable for business environments where there is central administration, support and policy management. "Broad Reach" is one of major benefits of ClickOnce, but to me it has a broad reach where some control over the environment and support is available. For example a business can publish a ClickOnce application on its intranet and configure the policies accordingly so that internal users can use it or publish it to the partner companies together with certificates.
In such environment I can see how ClickOnce is going to replace the existing deployment mechanism for a smart client application but I am not sure whether Jen who wants to write an application for her golfing mates will have the same level of experience. ClickOnce is not going to solve the security vs. feature paradox. You are either doing safe operations allowed in the Internet zone or are doing something that could be harmful. To my grandma, the whole CAS business doesn't mean anything and trust to them is a binary concept, they can't rate it.
My personal opinion is that deployment of ClickOnce applications should be secure by default so we should not compare ClickOnce with ActiveX as I think we all agree the security model provided by ActiveX controls is far from ideal.
I agree that having an easier deployment mechanism and so a wider adoption for .NET platform is beneficial but I think having a more secure environment will result in an even higher adoption rate and a better reputation. - Anonymous
March 01, 2006
I have to agree with Jason here, IN THE REAL WORLD, why would any hobbyist code realistically need FullTrust/Intranet Zone security clearance?
In this example, it's far more likely that Jen has hacked in some feature that could have been done without needing escalated permissions (e.g. P/Invoking what could have been rewritten in .net, or writing to HKLM instead of storing config data properly). In that case, it'd still be more productive for her to fix the CAS issue than to switch over to unmanaged code or roll her own online installer system.
At the very least, IMO the elevated permission dialog for unsigned apps from the Internet should be VERY scary (lots of red warnings, etc.), scarier than a similar dialog from the Intranet zone. Then at least Jen has to justify this very scary dialog to her users (and herself).
As for the legacy apps being ported over, that may require P/Invoke, etc., 99% of the time they will be hosted on your intranet, not off some random website. - Anonymous
March 01, 2006
Sure you've "heard it from others". But nobody at MS actually seems to even acknowledge the hearsay.
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=5b309bf8-370d-4571-8ce2-aaebb525488b - Anonymous
March 01, 2006
"IN THE REAL WORLD, why would any hobbyist code realistically need FullTrust/Intranet Zone security clearance?"
Most hobbyists don't want to hassle with differentiating between what is full trust and what isn't. If the development tools force them to hassle, they'll look for another set of development tools. This being a free, capitalist market, they're likely to find them.
I worked for a while as a WinForms PM. Making sure Whidbey WinForms apps could stay in the sandbox was one of my tasks. In the end, the organization decided to take the approach it did with ClickOnce and permission elevation. Why? Because staying in the sandbox requires jumping through hoops, doing things differently than you'd otherwise have done them in, say, the VB6 world. E.g., Jen will go out of the sandbox if she needs to perform the simple trick of making a WebRequest against a server other than the application's origin server. She'll be WAY out of the sandbox if she wants to build something that creates, enumerates or modifies existing files on the user's local drive (search DOC files, organize your music collection, export reports for use in Word or Excel, etc.).
There are many, many types of apps that can't stay in the sandbox. Saying "just avoid p/invoke" doesn't cut it. - Anonymous
March 02, 2006
For users who commented on our lack of FireFox support in ClickOnce and the lack of clear messaging from Microsoft I have posted the following blog -
http://blogs.msdn.com/saurabh/archive/2006/03/02/541988.aspx
Please feel free to comment on it and let us know your thinking/suggestions on this issue. - Anonymous
March 09, 2006
The comment has been removed - Anonymous
March 17, 2006
The comment has been removed - Anonymous
March 20, 2006
OK, desktop support found that there was corruption in the local settings folder. They fixed this by deleting the local settings folder and logging back in, causing the OS to recreate the local settings folder. After that, ClickOnce worked.