Re: Sun speaks out - but not to the cypherpunks
Pardon the flame but I really have just about heard enough of this BS...
This response came from Sun to Risks:
Date: Mon, 16 Oct 1995 21:22:40 -0700 From: Caveh.Jalali@eng.sun.com (Caveh Jalali) Subject: Re: Risks in Java
If we are going to "analyze" java security, let's keep in mind that there is an important distinction between the language (java) and the machinery which runs the java program.
Java is a general-purpose programming language along the lines of C/C++. So, there is no doubt that its expressive power overwhelms our theoretician's abilities to predict java-programs behavior -- this is where we start getting into the halting problem, computability and other black magic. Basically, i don't think we can "trust" programs written in any *useful* programming language.
Read: We can't trust Java programs.
The area where we can (must) build trust is the computing base. Traditionally, this has been the OS, but in the case of java, it is the java interpreter (such as netscape 2.0 and hotjava). The browser is now the TCB (trusted computer base) for all practical purposes...
Read: The Java interpreter is supposed to be a TCB
And, to address the specific concern about applets spamming the net -- from what I've seen, applets are only allowed to connect to the server that supplied the applet in the first place (by default). The worst thing one could probably pull off is to spam oneself.
Read: By default only - also note, none of this invalidates attacks 30-49 from the previously posted list.
Who here truly believes that the implementations of Java meet the requirements of a TCB?
-- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
Dr. Fred, you seem to spend a lot of engery slamming Java and HotJava. Are you unaware that the HotJava Platform is the first generation pass at an inline extensible GUI harness. Underline the total concept "extensible GUI harness". This includes a series of tool functions to *help* perform secure messeging (like those supplied iun Netscape 2.0/Java.), but because of the enormity of the task and the number of facets on the face of this gem it will be some time before the final versions of the first generation will be available. No one else had been working on this piece of technology before SMCC started their effort. From the word floating about the SMCC labs they didn't even know what they had. So rather than slamming them, SMCC, or their PR folks for - releasing a version of a development tool far beyond what the "big boy's - doing what PR people do - Minimize and Maximize concepts in the press I hope that you understand my point?. The net/net is that OLTP needs to be scaleable to be a saleable commodity and without the ability to do "java-ish" like local applets... There is no clean way to do this, ***period***. Also that OLTP requires transport level security, transaction level security , and a whole lot of systems security and authtication. The browser is the harness not the complete tool suite at this juncture. As an aside - What blows my mind is the number of cycles people spend bitching and moaning about Java itself rather than working to create a better solution. I just want to say "Get a clue. Moan about something that is important and pertinent to the technologies at hand". These comments are my own - Sincereley, Todd Glassey todd@lgt.com
participants (1)
-
todd@lgt.com