This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!
Relationship to Type Safety
Type safety is usually discussed in terms of what it does, e.g. guaranteeing encapsulation between different objects, or in terms of what it prevents, e.g. memory corruption by writing where one shouldn’t. However, from the point of view of the Virtual Object System, type safety is about guaranteeing:
- References are what they say they are - Every reference is typed and the thing referenced, the definition, also has a type, and they are compatible in a strict sense.
- Identities are who they say they are - There is no way to corrupt or spoof an object, and by implication a user or security domain. The access to an object is through accessible functions and fields. An object can still be poorly designed. The key is that a local analysis of the object and the things it uses, as opposed to a global analysis of all uses of an object, is sufficient to understand the vulnerabilities
- Only appropriate operations can be invoked – The reference type defines the accessible functions and fields. This includes limiting visibility based on where the reference is, e.g. protected fields only visible in subclasses
The Virtual Object System promotes type safety e.g. everything is typed. Type safety can be optionally enforced. The hard problem is determining if an implementation conforms to a typesafe declaration. Since the declarations are carried along as metadata with the compiled form of the program, a compiler from IL to native code (see Type Safety and Verification) can type-check the implementations. When coupled with code signing, the issue is then when to type-check and when to trust. For more information, see the security specifications.