Re: Sun speaks out - but not to the cypherpunks

[anonymous-remailer@shell.portal.com]

Todd Glassey <todd@lgt.com> writes:

> Pardon the flame but I really have just about heard enough of this BS...

No one needs to listen to anything if they don't want to, Todd, but I 
think that some things need saying none the less.

I think the old saying is: You can lead a horse to water, but you can't 
make him think, or something like that ...

>>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. 

Hmm, this is a very interesting prespective, coming from Sun Engineering
as it were. The company that says that the Network is the machine, or
somesuch.  I always thought that security consisted of everything: 
hardware, software, and wetware. 

(Or it did the last time, I checked my handbook.)

Admittedly this is a horrible inconvenience, especially when it comes to
security. 

>>> 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.

This may well be true.  But sloppy design, design which ignores the most 
basic difficulties cannot be brushed away by simply saying that "it 
exceeds theoretician's predictive abilitiies."

That simply doesn't cut it.

"Ignoring the obvious" is simply that.  It's a planned process of
"ignoring the obvious". 

One example of this that should serve as a useful case study is a recent
problem which was brought to the Canadian public's attention just this
week, on a program called the Fifth Estate.  The CBC (Canadian
Broadcasting Corporation) detailed a software code problem in one of
AECL's (Atomic Energy of Canada Limited's) instruments which deliver
penetrating radiation. 

The software which controlled the radiation dose, would periodically
override the oncologist's calibration and deliver a radiation dose 100
times what was prescribed.  This software "bug" literally killed wherever
the machine was in use. 

A simple hardware solution engineered into the product as part of a
redundancy check program would not only have saved many lives, but could
have confirmed that there were serious code deficencies.  A redundancy
program which AECL did NOT have. 

Then again AECL did not consider that it had to mathematically prove it's 
code either.  So I guess, they "ignored the obvious" not once, but twice.

A simple lesson can be learned here, one which I believe is applicable to
Java. 

If your parameters are going to be that you cannot trust your production
code, then you MUST engineer on that basis, that the production will not
be trustworthy, rather than simply crying like Chicken Little, that
mission critical applications must simply "live with" engineered
inferiority. 

Or alternatively, another lesson could be pulled out:  To avoid this 
problem, ensure that your code is mathematically provable or utilize 
appropriate hardware overrides.

Case study, #2:  Netscape.

During their code design, they assumed that all servers on a network were
trustworthy and would continue to be trustworthy.  They designed their
product on that basis.  In fact, over time the very opposite will be true. 

As an exploitation algorithm propogates, the significant percentage of
servers which are NOT trustworthy will begin to grow exponentially. 

The true assumption which Netscape should have started with is a simple 
one, and is the only assumption that ANY production house can start 
with:  that the network has a reliable transport mechanism, one which will 
route around damage.  That's it.  Any other assumptions are poor design 
and engineering and are demonstrative of a misunderstanding of the 
environmental conditions in which the engineered product is expected to 
perform.

>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.

I can't speak for "Dr. Fred", but I always worry when people start to
refer to something as a "gem", and start talking about the "enormity of
the task".  Especially if an engineer starts talking in such lyrical,
flowery prose.

Enormous tasks always lead to complexity which can never be solved by
simple linear thinking.  And the engineer from Sun is right, that it will
be some time before first generation products are available.  

(This will certainly be the case if "mathematical proofs" become mandatory
as part of an ACT in Action plan.  )

>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

Well, I'd rather that marketers stick to marketing AFTER a product 
development cycle is completed.  Generally, you would think (hopefully) 
that people who are technologists, just *might* have a better knowledge 
of what they have, (or don't have) wouldn't you?

Maybe??  Or maybe not ...

After all you wouldn't want some kid, some little snotty brat, some kid
who started playing around well over a decade ago -- when he was in his
teens -- as a projadmin on one of Honeywell's Multiplexed Information and
Computing Service beasts showing you up for your temerity?  

Or would you cry about the "kid" slamming you? 

>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,

Well if we're gonna bottom line it, and talk turkey, and leave Chicken
Little back at the table, skewered as it were, I'll extend a helping hand. 

The net/net is really, really simple, a product that doesn't perform as
advertised is not a saleable commodity.  No one buys cars which don't
start or cans that leak.  Sure you can have a body by Pininfarina or one
by Alcan but if the engineering isn't there under that beautiful skin then
you don't have ANYTHING TO OFFER FOR VALUE. 

>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.

Well. It's just not my responsibility to create a solution.  And I have a
tendancy not to "bitch and moan".  I might be one sarcastic castrating
SOB, but bitchy and moany is not something I'm routinely accused of. 

I simply have a reputation for a degree of frankness.  Nothing personal is
meant by it.  I'm actually a very nice person. 

Truly.;-I

>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 -

Appreciated.  And I mean that with sincerity that your comments are
appreciated.  I understand that each person here DOES express their
individual opinions.  Sometimes some very strong opinions.  Myself
included. 

Generally, wallflowers will not find comfort on this list.  We'll 
recommend that those people should stick to writing browser programs.

Oops, scratch that last thought ...

>Sincereley,
>Todd Glassey
>todd@lgt.com


Alice de 'nonymous ...

                                  ...just another one of those...


P.S.  This post is in the public domain.
                  C.  S.  U.  M.  O.  C.  L.  U.  N.  E.