Writing Mobile Code Essential Software Engineering for Building Mobile Applications [Electronic resources] نسخه متنی

Items Not in the First Version of the .NET Compact Framework

Security Checks

The concept of evidence-based permissions was central in the design of the Common Language Runtime, which serves as the basis for both the desktop .NET Framework and the .NET Compact Framework. This concept is also commonly referred to as code-access security.

Code-access security offers the ability to define and administer policy that assigns code-execution rights based on evidence provided by the code in question. Evidence can consist of things such as a cryptographic signature verifying the publisher of the component, the strong name of the component itself, the location where the component is installed in the local file system, or the URL from which the component was downloaded. Based on the evidence supplied and the local policy on the machine running the code, specific permissions can be granted to code. Examples of possible permission levels include the following:

Full trust
The code runs with full trust on the system and can do anything a native application could.

Restricted access to the file system
File I/O can be forbidden or restricted to certain directories based on the evidence a component provides.

Restricted access to user interface
The ability to bring up user interfaces can be permitted or denied components.

Network access
The ability to access the network can be permitted or denied components.

Native code access
The ability to call into native code can be permitted or denied components.

These and many more permissions are available and can be set as policies on the desktop and server .NET Framework. Much literature and documentation exists on this topic.

The .NET Compact Framework was designed with the ability to support this policy-based security model. In the first release of the .NET Compact Framework, however, the policy is simply defined as "all code has full trust." This means that applications targeting the .NET Compact Framework v1.1 running on devices run with the same set of permissions as native code does on the device.

The decision to pin the security permissions at "run at full trust" for the first release of the .NET Compact Framework was made for pragmatic reasons. Based on discussions with early adopters, it was apparent that the first wave of compelling mobile applications for devices would generally consist of applications that were explicitly installed by a user or an administrator on the devices and not downloaded and run on-the-fly. These kinds of applications were essentially replacing traditional native code applications for the devices, and because of this a similar permission model was appropriate. Given an infinite amount of time to design, build, test, and refine our security policy based on customer feedback, we would have built a more sophisticated model in the first version. However, after much discussion, it was apparent that this was not a requirement for applications to be successful in our first version. Because of this, the building of a sophisticated security policy engine was deferred to a following release in favor of the other feature work that went into the first version. It was a tough decision, but looking back on it we believe we made the right choice. It is worth noting that on some mass-market devices such as some smart phones there exist on-device security policies that require native code applications to have approved cryptographic signatures; managed-code applications are subject to the same policies on these devices.

Moving forward, it will be desirable to enable a security model that supports downloading code on-the-fly and assigning permissions based on evidence supplied by the code. For this reason, it is likely that future versions of the .NET Compact Framework will have several graded levels of trust and permissions, ranging from evidence-based "full trust" to very limited capabilities for lower-trust code. In addition, different kinds of mobile devices will likely have different policies set on them. Some devices will have policy set by end users, some by administrators, some by hardware manufacturers, and some by network operators who host the devices. The code-access security model is built to support this.

Multimedia

Mutimedia support was another area we chose not to explicitly support in the first version of the .NET Compact Framework. This means that developers wanting to do things such as play sounds or show videos will have to call native code to do this. As above, if we had had an infinite amount of time and space to develop, test, and refine these concepts, they would have been supported in the first release of the .NET Compact Framework. The practical feedback we got from our early adopters was that this was not a success-limiting factor for the kinds of applications people needed to build presently. Future versions of the .NET Compact Framework are likely to add richer multimedia support. Looking back this has also seemed to be a correct decision.