Trusted Applications

Relaxed Cross-Domain Access Restrictions

Trusted applications can perform networking and socket communication without being subject to cross-domain and cross-scheme access restrictions. For example, an application installed from one sub-domain using the HTTP protocol can access media files from a separate sub-domain using the HTTPS protocol. For more information about cross-domain communication, see HTTP Communication and Security with Silverlight.

Additionally, trusted applications can use the networking classes in the System.Net.Sockets namespace with relaxed policy checks. These classes include the new UdpAnySourceMulticastClient and UdpSingleSourceMulticastClient classes.

Trusted applications can create a TCP connection to any port on any host without the need for a cross-domain policy file. The destination port is no longer required to be within the range of 4502-4534. Similarly, trusted applications that use the UdpAnySourceMulticastClient and UdpSingleSourceMulticastClient classes can join any multicast group on any port greater than or equal to 1024 without the need for a policy responder to authorize the connection. For more information, see Network Security Access Restrictions in Silverlight.

Relaxed User Consent Requirements

Sandboxed applications require user consent to access the functionality provided by the StaysFullScreenWhenUnfocused setting of the Content.FullScreenOptions property and the Clipboard, AudioSink, and VideoSink classes. Trusted applications do not require user consent except when accessing the AudioSink (microphone) and VideoSink (camera) functionality.

Relaxed User Initiation Requirements

Several features in Silverlight require that you use them in response to user-initiated actions, such as button click events. You must also use these features within one second of the user-initiated action. This requirement is a security feature to prevent applications from spoofing operating-system functions.

Trusted applications can use most of these features without a user-initiated action. For example, you can enter full-screen mode in an Application.Startup event handler or write to the Clipboard after a lengthy formatting operation.

Full-Screen Support

As mentioned in the previous sections, trusted applications can enter and stay in full-screen mode without requiring a user-initiated action or user consent. Trusted applications can also use the StaysFullScreenWhenUnfocused setting of the Content.FullScreenOptions property.

Additionally, trusted applications that enter full-screen mode will not display the message "Press ESC to exit full-screen mode". Trusted applications do not automatically intercept any keystrokes and do not have any keyboard restrictions in full-screen mode.

One consequence of the keyboard-restriction change is that pressing ESC will not exit full-screen mode in trusted applications. This enables you to use the ESC key for other functionality. However, you must provide your own user interface for exiting full-screen mode.

For more information, see Full-Screen Support.

Support for Window Customization

Trusted applications can hide the title bar and border of the out-of-browser application window in order to provide a completely customized user interface. For information about enabling this feature, see How to: Configure an Application for Out-of-Browser Support.

When you hide the title bar and border, Silverlight displays only your application content over a white background. Because the background is not transparent, you cannot use this feature to create irregularly-shaped applications. However, you do have the option to use rounded corners, which have a corner radius of 9 pixels. For more information, see the WindowSettings.WindowStyle property.

To replace the functionality provided by the title bar and border, you can use APIs of the Window class. To enable users to drag the window or window borders, use the DragMove and DragResize methods. You can also adjust the window position and size by using the Left, Top, Width, and Height properties. To enable users to minimize and maximize the window, use the WindowState property. To enable users to close the window, use the Close method.

File System Access

Trusted applications can access System.IO and related types that are otherwise unavailable. This enables you to access user files directly without using the OpenFileDialog and SaveFileDialog classes.

In Silverlight 5, trusted applications have unlimited access to the local file system. In earlier versions, however, trusted applications can access only files in user folders, specifically the MyDocuments, MyMusic, MyPictures, and MyVideos folders.

Note:
These folders are distinct from the Windows 7 Libraries named Documents, Music, Pictures, and Videos. These library folders typically combine the contents of the user folders with other folders, such as shared media folders. However, trusted applications cannot access non-user folders except through the OpenFileDialog and SaveFileDialog classes.

You must use the Environment.GetFolderPath method to obtain the paths to the user folders. You cannot specify these paths directly.

The following table lists the classes in the System.IO namespace that trusted applications that target Silverlight 4 can use. The table also indicates which members of each class are not supported.

For more information, see the indicated reference topics and How to: Access the Local File System in Trusted Applications.

Native Integration

Trusted applications can access some capabilities of the native operating system. For example, on Windows, trusted applications can use Automation features and access or manipulate components exposed by the Office suite and other applications. In addition, in Silverlight 5 you can make platform invoke calls to unmanaged functions.

For more information about interoperating with Automation, see AutomationFactory and How to: Use Automation in Trusted Applications. For more information about using platform invoke, see How to: Call Unmanaged Code from Trusted Applications.

Determining Whether an Application is Trusted

To determine whether an application is currently running in elevated trust, check the HasElevatedPermissions property. This is useful to provide alternate code paths when an application runs in partial trust.

Security Considerations

Although trusted applications do not have full access to the host computer, they can access personal data and potentially cause harm. Therefore, you should treat them as full-trust applications when you perform security evaluations and audits. To prevent users from installing or running trusted applications, system administrators can use machine policy settings to deny access, as described in the "Policy Restrictions for Elevated Trust" section of this topic.

Trusted applications run with user privileges even if they are installed by users with administrator privileges. However, trusted applications can run with elevated privileges while debugging during development, so be sure to test accordingly.

Silverlight runs all application code within an AppDomain instance that has a uniform set of privileges (trusted or sandboxed). It is the responsibility of application developers to verify and validate any external components aggregated into an application.

Out-of-browser applications are no more secure than their host Web sites. Therefore, users must rely on the security of the host site when installing or updating an out-of-browser application. The following list describes some of the actions you can take to help enhance security.

• Sign your applications as described in the "Application Signing" section of this topic.

• If your application accesses resources from its host server, it should verify that the SilverlightHost.Source property value matches the expected site-of-origin URI.

• If your application handles sensitive information or loads additional code from the server, use HTTPS for the application URI and for secure communications. Note that the URI (including protocol) of the original application is always used when checking for updates.

• Out-of-browser applications can access network resources over HTTPS when a connection is available. Expired or invalid certificates will result in failed networking calls. However, there is currently no built-in indicator of the presence of a secure channel. To increase user confidence, consider providing your own indicator.

In-browser trusted applications are subject to restrictions imposed by browser security settings, such as Internet Explorer Protected Mode

For more information and general Silverlight security guidance, see Security.

Application Signing

Adding a digital signature to your trusted application is an important step to help secure the application and increase customer confidence during installation. Additionally, only trusted applications with valid digital signatures can use the out-of-browser update mechanism. To update a trusted application that does not have a valid signature, users must uninstall the old version and install the new version manually. In Silverlight 5, trusted applications must also have a valid digital signature to run inside the browser. For more information and additional requirements, see How to: Enable Trusted Applications to Run Inside the Browser.

To add a digital signature to a trusted application, you can use the Signing tab of the Visual Studio project designer. To do this, select <ProjectName> Properties from the Project menu, click the Signing tab, and then select Sign the Xap File. You can then use the available buttons to select an existing Authenticode X.509 code-signing certificate or create a test certificate.

You can also add a digital signature by using the SignTool.exe utility with an Authenticode X.509 code-signing certificate. For example, you could use the following command line:

signtool sign /v /f certificateFile.pfx fileToSign

For more information, see SignTool.exe (Sign Tool).

Code signing is relevant only for trusted applications. Silverlight verifies the signature and certificate whenever a user installs or updates the application. Users can install a trusted application without a valid signature. However, Silverlight prevents trusted applications from updating unless both the original application and the update are signed with the same valid, code-signing certificate. Additionally, the certificate must not be expired at the time of update. Be sure to take the certificate expiration date into consideration in your deployment and update planning.

Note:
Silverlight does not prevent application updates when the site-of-origin host is localhost or 127.0.0.1. This enables you to test your update code without a digital signature.

For more information about updating applications, see Out-of-Browser Support.

Policy Restrictions for Elevated Trust

System administrators can configure computers to prevent users from installing or running out-of-browser applications that require elevated trust.

If installing trusted applications is disabled, attempting to install one will have no effect. In this case, trusted applications that are already installed (or are installed by the administrator) will work correctly.

If running trusted applications is disabled, attempting to run one will display a blank out-of-browser application window. Typically, however, if running trusted applications is disabled, installing them will also be disabled.

For more information, see Group Policy Settings.

Version Notes

 Silverlight for Windows Phone and Silverlight 3 do not support trusted applications.

See Also

Tasks

Reference

Concepts

Other Resources