The Secure Object Format is a representation for mobile code in a secure distributed computing environment. The primary goal of the project is to insure that any program represented in this format can be safely run on your system.
Elements of the project include:
Doesn't Java already do all this? Not really.
The Java classfile format comes close to being secure. One can imagine making the necessary changes to make it secure, but not without breaking most existing Java programs.
Even if those changes were made, the Java verifier is based on a complex set of rules. Should the verifier pass a piece of code which violates any of those rules the integrity of the system is compromised. In contrast, the Secure Object Format verifier consists of little more than bounds checking. Any code which is successfully parsed and references no locations outside of the locally declared bounds is inherently capability secure. Elements of a secure system which must be correct to maintain the security should be as simple as possible. The Secure Object Format verifier meets this criterion, the Java verifier does not.
The standard Java libraries make no pretense of maintaining the capability security which the underlying class format nearly provides. While this could be addressed by replacing the appropriate parts of the Java libraries, almost all existing Java code would fail under the new system.
First there was hand wiring of machine components together. The programmer had direct access to anything the machine could do, but reprogramming was tedious and error prone.
By limiting the ways in which components could be interconnected, the connections could be specified as codes stored in memory rather than as a circuit diagram. Thus, machine language was born of a restriction in the ability to interconnect computing components.
Assembly language, while technically providing access to anything that could be done with machine language, placed a separation between code and data. The programmer was no longer aware of the numeric values of the machine instructions being coded, and so was less tempted to pluck a needed number from out of the code area.
FORTRAN added yet another layer of indirection between the programmer and the machine. Along with it came more rules for what could be done with pieces of data. A particular area of memory was now marked as containing a particular kind of data, like a floating point number for example. The compiler wouldn't let you do integer arithmetic on a floating point number (at least in theory). It was no longer possible to generate arbitrary sequences of machine language instructions. The higher level of abstraction more than made up for the restrictions.
The C language discouraged the use of arbitrary branching, giving the programmer a firmer idea of the state of computation at any given point in the program. The use of structs as a data abstraction encouraged the grouping of functionally similar data together.
Object oriented programming techniques took this grouping of data to a new layer of abstraction through data hiding. By restricting the use of pointers, the programmer is forced to group all of the code which can affect a piece of data together with the description of that data.
Capability security takes this a step further by removing access to all routes whereby the data hiding restriction of object oriented programming can be bypassed. With the addition of these restrictions it becomes possible to prove various security properties of pieces of code.