Re: Sun speaks out - but not to the cypherpunks

[todd@lgt.com (Todd Glassey)]

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