From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Wed, 10 Apr 1996 11:13:49 -0400
From: David Lukes davel@morgan.com
Subject: Java delenda est
Topicbox-Message-UUID: 42cc500c-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19960410151349.4uYDhFYPvG0kJQI-qIO1W7J4KIak75d-M7byOvByKOs@z>

Sorry about the off-topicness of this,
but I think it's slightly warranted.

After this, can we all go back to discussing Plan9, please?
(Or maybe inferno, but NOT Burroughs and Java).

On Apr 10,  7:38, yarvin-norman@CS.YALE.EDU wrote:
> 	1. The best way to handle Java security would be to do it in the
> 	operating system

Hear hear!

> 		The way Java security is currently done is a lot like
> 	the way security for normal programs was done on certain old
> 	Burroughs machines: there is no hardware protection which
> 	constrains Java programs, but instead the compiler is
> 	privileged software, which is trusted not to output bad code.

This is not quite accurate wrt Java.
On the B5000 et. al.,
the compiler DID take responsibility for the integrity of the whole system
by doing array bounds checking etc. etc. (*lots* of etc. etc.).

In java, the java loader takes on this responsibility,
verifying the bytecode before it's executed,
and relying on runtime checks for the remaining possible insecurities.

(If the security was in the compiler,
 a malicious user could send down a hand assembled
 java bytecode program to do whatever they liked).

> 		I'm not aware of what specific problems have been
> 	encountered either with the old Burroughs machines

How about compiler bugs crashing your system?
Thus compiler development required a tolerant user population,
a lot of midnight oil or a dedicated system.

As an aside,
since the file system needed to be strongly typed,
so that only a compiler could output executable files,
this gave rise to interesting problems when saving and restoring from tapes ...

>       or with
> 	Java,

Netscape and/or Sun have already had at least one bug that allowed Joe User
to subvert Internet firewalls using java applets. (Cute name, eh?)

Fundamentally the 2 approaches are the same:
you have to trust some piece of complex and fallible software with
some part of your systems' safety,
and unless that piece of code and everything it depends on,
have been formally verified (yeah, right),
you will, at some point it time, lose,
when an exploitable bug appears.

(I'm not saying OSs are perfect,
 but they keep all your security bugs in one place ...)

End of diatribe, back to normal programming.

	Dave.

P.S. Personally, when I think of Java, I think of Krakatoa and boiling lava ...