From: "Perry E. Metzger" <perry@piermont.com>
Date: Tue, 4 Jun 1996 14:23:04 +0800
Subject: Re: Java Crypto API questions
In-Reply-To: <199606040113.SAA02369@springbank.eng.sun.com>
Message-ID: <199606040200.WAA06306@jekyll.piermont.com>
MIME-Version: 1.0
Content-Type: text/plain



Benjamin Renaud writes:
> >Good thing Sun is spending millions pushing a brand-new language
> >down our throats so we can do nothing we couldn't already do.
> >After all the hype about security, security models, and sandboxes
> >we get signed applets that can do anything.  What a let-down.
> 
> Just to clarify a couple of things. We're not pushing anything down
> your throat. You are still perfectly free to use Visual C++ if that is
> what you prefer.

Why, thank you. However, you haven't answered Mr. Lowenstern's point.

Once you start signing Java apps, and executing them based on the
trust implied in the signature, you really didn't need Java in the
first place. You could just download and execute programs of any sort.

Frankly, I really dislike the idea of my users downloading arbitrary
apps all day long onto their workstations and running them. I'm not
sure it really buys you too much, either, other than loss of security.

> - We think that the ability to let applets have free reign is
> useful,

Lots of things are useful. Security often "gets in the way". However,
as mature engineers operating in an environment where many users have
highly mission critical equipment, some of us try to be more
responsible than that.

> The important thing to remember is that we're not going to come out
> with an implementation and claim to have solved the capabilities model
> problem.
> 
> We're taking a first step at using signatures with Java for security
> purposes, but this is only a first step. We remain fully committed to
> finer and more powerful security models. Note that an application
> written to the Java platform will be able to implement security
> policies based on digital signatures which are not fully permissive.

Java's security has always lacked defense in depth, continues to lack
defense in depth, probably cannot be retrofitted to gain defense in
depth, and is likely going to continue to be periodically
penetrated. Java security continues to rely on the "all portions of
the system are perfectly implemented" model, which as I have
repeatedly noted in this forum is fundamentally flawed because humans
can never produce perfectly designed and implemented systems. A system
that was built to be failure tolerant would be better, but that isn't
what you have proposed.

I have a great fear. My great fear is that once you've solved the
obvious and stupid problems and hyped how Java has become secure
(which will doubtless make the stock market analysts happy), people
may start to trust Java, and then, without warning, one day the evil
applets on the web pages aren't going to be mere demonstrations any
more but are going to be real nasty things that do stuff like embezzle
money from your brand new funky ecash purse or whatever. At that
point, it will be way too late to do anything because of all the Java
crud pervading the net that all the users will insist on having access
to.

All this, mind you, to get fancy animation on web pages, and damn
little else worthwhile.

Perry