Competition
	Home   |   About   |   Technology   |   Papers   |   Contact
	Competition Because the E platform and CapDesk are infrastructure tools, they touch on many different aspects of computing. We will deal with the competition in several segments: competing security technologies, competing distributed software development technologies, and competing desktops. Security Technologies The security technology field is broken into hundreds of specialized applications for specialized purposes, which is perhaps one of the best indicators of just how problematic all the existing technologies are. Combex has demonstrated that security can coexist with flexibility and power, but there is another point less often noted in the common wisdom but which is truly inescapable: Security cannot coexist with complexity. Complexity invites the identification of chinks in the armor. Here we consider 2 of the more general-purpose and common security systems: access control lists as found in Unix and Windows NT, and firewalls such as the Linux IPCHAINS utility. Firewalls: firewalls are inherently unable to implement POLA. They are perimeter security systems only (though the perimeter may be applied to a single computer, for those willing to administer such systems). Once an infection has breached the perimeter, all the materials and machines within the perimeter are immediately open to convenient assault. In a POLA-based security regime, acquisition of a single authority does not assist in acquiring the next authority. POLA by its nature yields defense-in-depth architectures, both on the desktop and on the network. And although a firewall may be able to use virus detection software to catch and delete well known viruses before they infect the network, they cannot catch the brand new virus that has not yet been identified and is in its most infectious state. Access Control Lists: Access Control Lists (ACLs) as provided by Unix and Win NT are also inherently unable to implement POLA. It is possible, with acts of sufficient system admin legerdemain, to cast certain applications into their own private user spaces (web servers are frequently treated as separate users), but this is far too complicated for the user of a word processor that supports the creation of document-embedded viruses with an embedded programming language, or the user of a web browser that supports Active-X controls. All the currently popular security systems are designed as wrap-arounds for systems in which the security regime was inadequately addressed in the deepest underpinning layers. To meet the security needs of today’s extreme-security organizations, and tomorrow’s average user of Web-based smart contracting, a fundamental change is required: the type of change afforded by E and CapDesk. Distributed Software Development Technologies The premier languages of the Web today are Java and Perl. Perl is a powerful string-manipulation language for building short CGI scripts to drive simple data-driven Web pages. It is virtually useless once one leaves this important but limited niche: its lack of modularity and casual disregard for readability make it unusable for more complex applications. Java is a serious language for diverse professional purposes, and it does have a security architecture. CapDesk running a Web Browser that has launched an E caplet. Caplets deliver on the promise first made by Java applets: flexible powerful applications downloaded over the Web that can be run safely on the local machine while still being centrally maintained. Note the Save button on the Caplet, which is impossible on a Java Applet because of the restrictions imposed by the Java Sandbox The Java Security Manager is not, strictly speaking, capable of implementing POLA. However, close inspection of the documentation shows that, in principle, it comes surprisingly close to supporting POLA. Alas, there is a fatal flaw in the Security Manager: using this fine-grain security imposes such a complexity burden on the user that, in practice, no one ever uses it. The Security Manager has 3 basic settings: The Java Sandbox for applets. The Java Sandbox is almost completely confined. It is sufficiently confined so that applets are unusable—if you wrote a spreadsheet applet, for example, the user could spend hours in your applet developing the perfect model, only to find that he cannot save his work in a local file because the applet does not have authority to write a file. The sandbox does, however, grant the authority to send your data back to the applet’s owner. As a consequence, it is easier to make applets that steal your data than it is to make applets that save your data. The Java Application Environment. In the Java Application Environment, the security manager is effectively turned off, and the application has the same authority to read, edit, steal, and delete your data as does any application written in C or FORTRAN. The Certificate Authenticating settings. This is not a single setting, rather, it is the whole collection of other settings which turn different authorities on and off based on certificates. The executives of Combex have never seen, heard of, or read about anyone actually using these settings in the field. They are simply too complicated for practical application. This contrasts starkly with CapDesk, in which well-understood user interface machinery such as the File Dialog and the drag-drop metaphor perform security and authorization functions transparently for the user during normal operations. In the specific niche of secure distributed application development, Java has a number of other disadvantages compared to E, including these: The Java concurrency architecture is based on threads, which encourage the creation of delicate software systems that are vulnerable to sudden and catastrophic lock-up after deployment because of undetectable deadlock bugs Communication via RMI is not transparently encrypted. The RMI protocol is inherently insecure even if the communications pipes are encrypted In a very important sense, Java should not be looked upon as a competitor. The E platform runs on top of the Java Virtual Machine; all E programs are 100% Pure Java according to the definition promulgated by JavaSoft.