Home > Articles > Security > Network Security

ClickOnce Security

Brian Noyes discusses different aspects of deployment security and gives you a solid understanding of what protections ClickOnce provides and how you can customize those protections to suit the needs of your particular application.
This chapter is from the book

WHEN PLANNING FOR DEPLOYMENT, you need to consider a number of different aspects with respect to security. You need to consider

  • How to protect the client machine from being compromised by your application's installation or execution
  • How to protect the application files from being tampered with on the deployment server
  • How to implement authentication and authorization based on the user's identity
  • What you want to allow the application to do based on the identity of the application publisher

ClickOnce, the .NET Framework, and the Windows operating system provide facilities to address all of these considerations. This chapter will discuss these different aspects and give you a solid understanding of what protections ClickOnce provides, and how you can customize those protections to suit the needs of your particular application.

ClickOnce Security Overview

ClickOnce is designed to be a trustworthy deployment mechanism for smart client applications. This means that ClickOnce is designed to protect the client machine from being harmed by applications that it deploys. ClickOnce provides protection for the client machine at install time and at runtime, ensures that the client machine and users can identify who the publisher of the application is, and protects the application's files to ensure than no one can tamper with them after the publisher has published the application.

ClickOnce runtime protection is based on the application's identity, not on the user. ClickOnce is specifically designed to enable low-privilege users to deploy and launch smart client applications without administrator intervention. The user identity is not used directly by ClickOnce in any way. However, that does not mean that your ClickOnce application will be unprotected with respect to user privileges either. You can take advantage of .NET role-based security to prevent users from using functionality in your application if they do not have sufficient rights. Additionally, the client machine's operating system will still enforce access controls based on the logged-in user, such as limiting access to files, folders, or the registry if the user is not part of the access control list for those resources.

ClickOnce Deployment-Time Protections

ClickOnce security protection comes into play as soon as an application or update is deployed to the client machine. When files are deployed to the client machine through ClickOnce, they are isolated per user, per application, and per version under the user's profile. The application deployment itself is nothing more than a series of files copied into an isolated folder under the user's profile. If you have worked with .NET isolated storage before, the ClickOnce cache folders are similar in concept, but located in a different place under the user's profile. You cannot execute any custom installation steps that make modifications to the local machine as part of the ClickOnce deployment itself (see Chapters 7 and 8 for more information on custom installation requirements). As a result of this design, there is no way that the act of deploying an application to a client machine through ClickOnce can harm other applications or data on the machine.

ClickOnce Runtime Protections

ClickOnce and the .NET runtime provide runtime protections for the client as well. ClickOnce relies on the Code Access Security (CAS) infrastructure of the .NET Framework for enforcing those runtime protections, but ClickOnce security is configured and managed a little differently than for non-ClickOnce deployed applications. For a quick overview of CAS, see the sidebar entitled A Short Primer on Code Access Security.

ClickOnce security is applied at the application level, instead of at the individual assembly level as it is in a normal .NET application. Your entire ClickOnce application (the application executable and all assemblies that it loads) are treated as a single unit for the purposes of deployment, versioning, and security. When an application is deployed through ClickOnce, the application manifest specifies what security permissions the application needs to run. These permissions are based on CAS.

As the application is launched by ClickOnce, the runtime first evaluates what URL or UNC path was used to deploy the application to the client machine (the path to the deployment manifest on the deployment server). This path is treated as the launch path. Based on this path, the runtime associates your application with one of the built-in location-based code groups (My Computer, LocalIntranet, Internet, Trusted Sites, or Restricted Sites zones). The runtime determines what set of permissions should be granted to your application based on the zone that it was launched from and compares that to the set of permissions requested by the application.

If the requested permissions in the application manifest are less than or equal to the set that would be granted based on the launch zone, then no elevation of permissions needs to occur and the application can simply launch and run. If the application attempts to perform an operation that exceeds the granted permissions, then a SecurityException will be thrown.

To see this in action, do the following.

  1. Create a new Windows Application project in Visual Studio, and name the project RuntimeProtectionApp.
  2. From the toolbox, add a button to the form.
  3. Double-click on the button to add a Click event handler for the button.
  4. Add the following code to the event handler:
    private void button1_Click(object sender, EventArgs e)
        StreamWriter writer = new StreamWriter('AttemptedHack.evil');
        writer.WriteLine('If I can do this, what else could I do??');
  5. Add a using statement for the System.IO namespace to the top of the file:
    using System.IO;
  6. Open the project properties editor (choose Project > RuntimeProtectionApp Properties).
  7. On the Security tab, check the checkbox labeled Enable ClickOnce Security Settings, and click the radio button labeled This is a partial trust application (see Figure 6.1).
    Figure 6.1

    Figure 6.1 ClickOnce Security Settings

  8. Publish the application by choosing Build > Publish RuntimeProtectionApp.
  9. When the Publish wizard appears, click the Next button.
  10. In the second step of the Publish wizard, select the option to make the application available online only (see Figure 6.2) and then click Finish.
    Figure 6.2

    Figure 6.2 Selecting Install Mode in the Publish Wizard

  11. Click the Run button in the publish.htm test page when it appears in the browser. This launches the application.
  12. Press the button that you added to the form in step 2, causing the application to try to write a text file to the current working directory (which in this case is the C:\Windows\Microsoft.NET\Framework\v2.0.50727 folder, since the application is marked for partial trust as discussed in Chapter 5).
  13. A SecurityException will be thrown for the FileIOPermission type, because the default LocalIntranet zone security permissions do not include that permission. The permission is demanded by the StreamWriter class when you construct an instance of the StreamWriter. Since the application does not catch the exception, the dialog shown in Figure 6.3 will display.
    Figure 6.3

    Figure 6.3 Unhandled Exception Dialog

  14. Click the Quit button to exit the application.

In this example, the application requested permissions that did not exceed the permissions granted by the launch zone. This is because you selected partial trust and the default zone for partial trust is the Local Intranet zone. When you installed the application by clicking on the Run button in the publish.htm test page, the address used was http://<your-machine-name>/RuntimeProtectionApp/RuntimeProtectionApp.application. The runtime evaluates this address to the Local Intranet zone (based on the server address portion of the URL: http://<your-machine-name>/) and compares the requested permissions in the application manifest to the permissions for that zone. Since they match, no additional prompting is needed based on security and the application launches.

However, just because the application only requests a certain set of permissions based on its manifest does not mean that there is not code in that application that might try to do some operation that exceeds the granted set of permissions. In this example, the application contains code that tries to perform a file write to the local directory. That operation triggers a check for FileIOPermission for the file that is being written. Since the Local Intranet zone does not include that permission, a SecurityException is thrown at that point.

These protections are designed to ensure that your application does not inadvertently do something on the user's machine that it was not designed to do. This could result from bugs in your code, debug code that was left behind unintentionally, or it could happen if your application manages to load some other assembly that does something more than you expect it to. For example, suppose you design a smart client application that acts as a data entry client for a distributed application. Based on your design, that application should only present a rich interactive user interface for the user to view, enter, and manipulate data that gets passed to your middle-tier application server through Web services.

Suppose you choose to use some third-party UI component to speed your development. Unknown to you, the code inside that component collects any values that are entered through its controls and transfers that data to some unknown location via a Web request for intelligence gathering. If you deployed this application with full trust, the component would be able to do just that and you may never even know it is happening behind the scenes. However, if you deployed your application with partial trust and restricted the WebPermission options to only allow calls to your middle-tier servers, then a security exception would be thrown when that nefarious component tried to do its evil deeds. By restricting the permission set, you would be protecting the user from that hidden data transfer.

Using a restricted set of permissions through partial trust is an excellent way to prevent your application from doing anything it was not designed to do. Unfortunately, for a lot of meaningful things that you might want to do in your application, such as doing on-demand updates through ClickOnce or making remote calls through Windows Communication Foundation, you will be required to set your application for full trust due to the more advanced things the Framework does for you under the covers to provide those capabilities. You can still lock down permissions for specific sections of your code, however (see the section Adding Restricted Code Sections later in this chapter for an example of how to do that).

If the application manifest requests permissions that exceed the launch zone permissions, such as full trust, then those permissions need to be granted to the application somehow so it can launch. This can be done either through user prompting (the default) or automatically based on trusted publishers. Both of these approaches are covered later in this chapter.

ClickOnce Size Limitations for Online-Only Applications

A partial trust online-only application can run without any user prompting, depending on the permissions the application requires and the zone it is running from. To prevent such an application from filling up the hard disk by downloading many large files, ClickOnce restricts the total size of a partial-trust online-only application to be half the online cache quota on the machine. This size is checked at download time as bits are being downloaded, and the ClickOnce launch will fail once the limit is exceeded. The default cache quota is 250MB, so partial-trust applications larger than 125MB should ask for full trust.

ClickOnce Tamper Protections

ClickOnce protects the files that your application is composed of by using digital signatures. When you publish an application with ClickOnce, you have to sign the deployment and application manifest with an Authenticode Class 3 Code Signing publisher certificate. Authenticode certificates are based on public-private key cryptography. Publisher certificates contain both a public and a private key. The public and private keys have a mathematical relationship that makes it so anything you encrypt with one of the keys, you can decrypt with the other. However, the complexity of the mathematical relationship is such that it is extremely difficult to come up with one key when you just have the other. With the strength of current cryptographic keys, it would take hundreds or thousands of years of heavy-duty computing to figure out the value of one key if you just know the value of the other.

As the names imply, the intent is that you keep one key (the private key) to yourself, but you can freely hand out the public key to anyone who wants it. Once others have your public key, you can encrypt a message or file with your private key and give the message or file to them, and they can decrypt it using the public key with a strong assurance that the message or file they decrypted actually came from you (or at least someone who has access to your private key). Likewise, they can encrypt a message or file with your public key and give it to you, and they can be sure that only you can decrypt that message or file and see the contents.

When you sign a file with a certificate, the signing mechanism computes a hash of the file's contents using cryptographic methods. In computing the hash, it disregards a reserved section of the file into which it will insert the digital signature once is has been computed. Once the hash has been computed, the hash is encrypted with the private key of the publisher certificate. The encrypted version of the hash is the digital signature. This signature and the public key from the certificate used to encrypt the hash are inserted into the reserved location in the file. Now anyone who receives that file can compute the file's current hash using the same algorithm that was used to generate the original hash. They can then extract the digital signature and decrypt it using the public key embedded in the file with the signature. After they have decrypted the signature, they have the original hash that was computed by the publisher. If they compare the original hash and the hash they just computed, they can confirm that no one has tampered with the file since it was signed by the publisher, because any modifications to any part of the file will modify the computed hash and it will be different from the original hash.

This approach is used by ClickOnce to digitally sign your deployment and application manifests when you publish your application. It is also used by .NET for strong naming assemblies. Strong naming is just a similar digital signature approach. In the case of ClickOnce, the digital signature is embedded in the manifests as XML. In the case of strong naming, the digital signature is computed when an assembly is compiled, and is embedded in the assembly manifest in binary form.

In addition to digital signatures providing a guarantee that the manifests have not been tampered with since you published your application, they also provide tamper protection for all of your application files. When your application manifest is generated, a hash of each of the files in the application is put into the application manifest along with the rest of the file information. When ClickOnce deploys or updates your application, it computes the hash of each file as it is downloaded from the server and compares the hash to the one embedded in the downloaded application manifest. Since the application manifest is signed and can't be tampered with to change the hash values for application files, there is no way for someone to tamper with any of your application files, because ClickOnce will refuse to launch your application if the application file hashes don't match after they have been downloaded.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020