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