Security And Trust

Security And Trust

This topic describes security and trust issues when deploying Tablet PC Web applications.


The .NET framework has a security model that treats different applications differently depending on their origin. Executables and assemblies that are from a user's machine generally run with full trust; the same executables and assemblies run over the internet will generally run with partial trust. This is to prevent malicious code from either reading or modifying information it should not have access to (local files, what's in the clipboard, etc.). If an executable calls an assembly, which in turn calls another assembly that requires a certain level of trust, then the lowest level of trust of all the components in the chain is applied. However, an administrator on a machine can set specific permissions that override the default permissions.

An overview of the security model is given in Secure, Light-Weight Client-Side Controls Leave Site, and you can obtain more depth about the security model in Code Access Security in Practice Leave Site. A good overview on the securities of libraries (which is especially important for System.Windows.Forms.UserControl Leave Site objects on a Web page) can be found in Using Libraries from Partially Trusted Code Leave Site, and other security information on managed controls can be found in Writing Secure Managed Controls Leave Site.


When called under partial trust conditions, most managed objects and members in the Microsoft® Windows® XP Tablet PC Edition Software Development Kit (SDK) require two permissions:

  • Execution Leave Site.
  • InheritanceDemand Leave Site. This means that a derived class inheriting a class or overriding a method from the Tablet PC SDK is required to have been granted the specified permission.

The following table lists the classes and members that require additional permissions. The permissions for a given class also apply to all of its members not listed in this table.

Class or MethodPermissions
Ink.CanPasteUIPermissionClipboard.AllClipboard Leave Site
Ink.CopyClipboardUIPermissionClipboard.OwnClipboard Leave Site
Ink.PasteUIPermissionClipboard.AllClipboard Leave Site
InkCollectorUIPermissionWindow.SafeTopLevelWindows Leave Site
InkCollector(IntPtr)UIPermissionWindow.SafeTopLevelWindows Leave Site and SecurityPermissionFlag.UnmanagedCode Leave Site
InkCollector.HandleUIPermissionWindow.SafeTopLevelWindows Leave Site and SecurityPermissionFlag.UnmanagedCode Leave Site
InkEditUIPermissionWindow.SafeTopLevelWindows Leave Site
InkOverlayUIPermissionWindow.SafeTopLevelWindows Leave Site
InkOverlay(IntPtr)UIPermissionWindow.SafeTopLevelWindows Leave Site and SecurityPermissionFlag.UnmanagedCode Leave Site
InkOverlay.HandleUIPermissionWindow.SafeTopLevelWindows Leave Site and SecurityPermissionFlag.UnmanagedCode Leave Site
InkPictureUIPermissionWindow.SafeTopLevelWindows Leave Site
RendererUIPermissionWindow.SafeTopLevelWindows Leave Site
Renderer.DrawUIPermissionWindow.SafeTopLevelWindows Leave Site and SecurityPermissionFlag.UnmanagedCode Leave Site
Renderer.Draw(IntPtr,Strokes), Renderer.Draw(IntPtr,Stroke)UIPermissionWindow.SafeTopLevelWindows Leave Site and SecurityPermissionFlag.UnmanagedCode Leave Site
Renderer.InkSpaceToPixel(IntPtr,Point), Renderer.InkSpaceToPixel(IntPtr,Point[])UIPermissionWindow.SafeTopLevelWindows Leave Site and SecurityPermissionFlag.UnmanagedCode Leave Site
Renderer.PixelToInkSpace(IntPtr,Point), Renderer.PixelToInkSpace(IntPtr,Point[])UIPermissionWindow.SafeTopLevelWindows Leave Site and SecurityPermissionFlag.UnmanagedCode Leave Site
DynamicRendererUIPermissionWindow.SafeTopLevelWindows Leave Site
RealTimeStylusUIPermissionWindow.SafeTopLevelWindows Leave Site and SecurityPermissionFlag.UnmanagedCode Leave Site
RealTimeStylus(IntPtr), RealTimeStylus(IntPtr,Boolean), RealTimeStylus(IntPtr,Tablet)UIPermissionWindow.AllWindows Leave Site and SecurityPermissionFlag.UnmanagedCode Leave Site

Note: It is always preferable to use a Control Leave Site rather than a handle (IntPtr Leave Site) for constructors since they require fewer permissions. Similarly, it is preferable to use a Graphics Leave Site object rather than a handle for Renderer.Draw, Renderer.InkSpaceToPixel and Renderer.PixelToInkSpace.

Other Issues

Some other known security issues are listed below:

  • When running under partial trust, the mouse and painting events are not fired for the InkCollector and the InkOverlay. Instead, you can subscribe to events on the control that the InkCollector or InkOverlay is attached to. If you require making the distinction between the Painted and Painting events, you will need to use the RealTimeStylus rather than an ink collector.
  • Microsoft Internet Explorer 6 or higher is required in order for Web controls to work properly. With Internet Explorer 5.5, only initial managed controls load; you cannot load additional controls dynamically at run-time.
  • If you are using Service Pack 2 (SP2) and CLR1.0, then having Web controls in Internet Explorer will require adding the site as a trusted site, even if they are in the Intranet zone. However, when you do so, they will no longer run in the Trusted Site zone, although they will run in the Intranet zone. This issue is fixed with CLR1.1.
  • If you have an InkCollector or InkOverlay attached to a window or control, and you switch it to another window or control, then you will need to have UIPermissionWindow.AllWindows Leave Site permission. If you are going to be building Web applications, it is preferable to keep your InkCollector or InkOverlay attached to a window until that window is going to be destroyed.