[email protected] (John Gilmore) writes: > Java was designed and initially implemented in a better, albeit naif > time. The notion that systems must be designed and implemented > defensively, that malicious attempts to corrupt or destroy them will > be frequent, was not yet understood (and has not yet been fully > assimilated).
some historic background ... java was mid-90s, we went to sun invitational, the head of the business unit I had worked with previously at ibm (he was one of two people responsible for IBM's pascal implementation, originally done for implementating internal vlsi tools) ... and then left and became vp of software at MIPs before becoming general manager of sun business unit that included java. we had discussions about what was needed for the java virtual machine to provide system integrity and security comparible to ibm's virtual machine product. we had been asked to look at running a effort to commercialize and release SUNs object-oriented "SPRING/DOE" operating system (this was back in the day when object-oriented programming, applications and operating systems were all the rage ... apple was doing one, sun did one, others were doing stuff) ... SUN was in the process of shutting down SPRING/DOE and transferring everybody over to JAVA. old email touching on the subject http://www.garlic.com/~lynn/2010.html#email960203 we've had past discussions about how much did the SPRING/DOE client implementation influence GREEN (which morphs into JAVA) http://www.garlic.com/~lynn/2003e.html#51 A Speculative question above includes URL/references to GREEN as well as description of the SPRING/DOE client-side interpreter (taken from the SPRING/DOE documents). previously we had been brought in to consult at small client/server startup that wanted to do payment transactions on their server, the startup had invented this technology called SSL they wanted to use; the result is now frequently called "electronic commerce". Part of the effort, we had done detailed, end-to-end, threat & vulnerability analysis for mapping SSL technology to payment transactions and came up with some number of deployment and use requirements. Some number of these requirements were almost immediately violated ... contributing to many of the exploits that have continued to this day. at the time (and since then), all the various browser client-side implementations (IE's visual basic, java, javascript, etc) were under significant pressures to take short-cuts to provide support for the latest & greatest client-side feature. for the payment transaction stuff ... I had sign-off authority on everything to do with the payment gateway and webserver interfaces to the payment gateway ... but could only recommend regarding the browser/client ... and their interfaces to webserver ... as well as webserver operation (other than the protocol to the payment gateway). -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
