ClickOnce Frequently Asked Questions

Security wise, how is ClickOnce improved compared to ActiveX?

Microsoft has designed ClickOnce from ground up to be a more secure technology than ActiveX. The following security improvements are noteworthy:

• ActiveX supported scripting; that the ActiveX control could be programmatically controlled with different parameters from a JavaScript in an HTML. Most ActiveX related incidents were misuse of well intended ActiveX controls which unintentionally contained security problems. ClickOnce cannot be scripted, and therefore reduces the risks of the unintentional vulnerabilities being exposed.
• ActiveX could be developed in many languages, many of them lacking built in memory management. Since the ActiveX controls often were not memory managed they could expose many unintentional security problems related to unmanaged memory (buffer overflows, dangling pointers, formation string vulnerabilities, ...). ClickOnce is built upon memory managed .NET Framework, which reduces these risks.
• All ActiveX controls were historically executed with machine access, allowing them to do anything. ClickOnce applications which does not require additional machine access (such as file access, network access, ...) can be designed. Such applications will run within a secure sandbox maintained by .NET, and will never be able to access machine/network resources. Applications built to be used this manner, are therefore protected from exposing any unintended vulnerabilities. (with the Windows Vista version of Internet Explorer 7, a protected mode feature was introduced to supply a kind of sandbox security protection to ActiveX as well).
• Both ActiveX and ClickOnce now are accompanied with an improved dialog for starting software from web pages. The improved dialog is designed to make it easier for users to make the right decision in regards to if they want and trust an application to be started.

Taking all this into account, ClickOnce is security-wise a superior technology to ActiveX. In particular, ClickOnce is considerably more secure than the historical design of ActiveX - which Microsoft has reworked in Internet Explorer for Windows XP SP2 to improve security and also further improved in Internet Explorer for Windows Vista.

Can I disable the security prompt? How?

Yes. The prompt is a configurable per zone basis, and it can be set to three different possible choices; Enabled, Disabled or AuthenticodeRequired.

• Enabled is the mode where the user always receives the prompt and makes all security decisions if the publisher is not trusted. Applications from trusted publishers will launch automatically.
• AuthenticodeRequired means that the prompt is disabled for applications where the publisher cannot be determined, and the user is only left to make decisions about application publisher is determined but not trusted. Applications from trusted publishers will launch automatically.
• Disabled is the choice for enterprises which don't want the users to have to make any security decisions; any untrusted application will be terminated with a dialog stating the application is disabled. Applications from trusted publishers will launch automatically.

There are five zones, MyComputer (default: Enabled), LocalIntranet (default: Enabled), Internet (default: AuthenticodeRequired), TrustedSites (default: Enabled), and UntrustedSites (default: Disabled). For each of these zones there is a corresponding registry string value in \HKLM\Software\Microsoft\.NETFramework\Security\TrustManager\PromptingLevel, but you may have to create it if not already present. To distribute the new settings across an enterprise network, implement a new domain policy for the these registry values.

An enterprise which wishes to increase security by restricting user from making unsafe choices, might consider e.g. setting Internet to Disabled, or setting LocalIntranet to AuthenticodeRequired.

Can I get my applications to run with high trust without requiring a prompt?

Yes!

The first step is to sign the the application with a valid code signing certificate. The second step is to add the code signing certificate to Trusted Publisher certificate store, and if necessary also add the root CA certificate to Trusted Root Certification Authorities and any intermediate certificates to Intermediate Certification Authorities store. Verify success by accessing the application!

In an managed enterprise environment, these steps should be performed using Group Policy to reach workstations. Using Domain Security Policy and add the corresponding Public Key Policies. Once the domain policies has been updated on enterprise workstations, the application will run without displaying the security prompt.

Why do manifests have to be signed?

The most important reason is that the security model for ClickOnce is designed to prevent someone from tampering with the ClickOnce files. By signing a manifest, it is ensured that the person/organization is the only one who can push new software updates into the ClickOnce application.

In this manner, ClickOnce makes it hard for viruses to infect a ClickOnce installation, as the virus cannot alter the ClickOnce code without render the signature invalid.

A manifest can be signed with a code signing certificate, which may either a dummy certificate generated for this purpose only (generating a "Unknown publisher" warning), or generated by a commercial Certification Authority (like Thawte and Verisign), or generated by Certificate Authority within the enterprise. The Obtain a certificate for ClickOnce deployment manual provides further information.

Signed manifests should hopefully also rise the bar for "evil doers" some. To obtain a code signing manifest recognized on the Internet, a certificate needs to be purchased from a commercial Certificate Authority - and this small costs may be enough to make some rascals to avoid doing this. A software being also makes easy to determine where it originates from, thus making it much harder to use for individuals who wants to anonymously get away with creating malicious software,

Are there any special server requirements for hosting a "ClickOnce" application?

No. ClickOnce can be deployed from most resources, e.g. file shares or a web server such as Microsoft IIS or Apache.

To configure a web server to host a ClickOnce application, first you may need to

• configure the MIME type (application/x-ms-application) for the .application extension.
• configure your server to unblock any restricted file extensions used by your application, such as .exe, .dll, .config., manifest, etc.
• optionally, if you want to use HTTP compression, you will need Microsoft IIS 6 or newer, or Apache with a compression module loaded.

Security can be improved by installing application server with HTTPS (SSL / TLS) network security protocol, which through the use of strong cryptography/authentication resolves most network threats (such as eavesdropping of communication).

Can I launch a ClickOnce application from any web browser besides Internet Explorer?

Yes, most Windows applications uses Windows standard URL activation, which is configured by .NET Framework 2.0 setup.

For some other software, additional configurations may be required. For Mozilla Fireforx a ClickOnce startup add-on is available at https://addons.mozilla.org/.

Can I install a ClickOnce application per-machine?

No. All “ClickOnce” applications are installed per-user. If your application needs to be installed per-machine, you should use managed deployment - copy the files to the workstations with Group Policies, SMS or another 3rd party software deployment product.

More information

Further information about Click Once can be obtained from Microsoft.