From: br@doppio.Eng.Sun.COM (Benjamin Renaud)
Date: Tue, 4 Jun 1996 13:19:48 +0800
To: andrew_loewenstern@il.us.swissbank.com
Subject: Re: Java Crypto API questions
Message-ID: <199606040113.SAA02369@springbank.eng.sun.com>
MIME-Version: 1.0
Content-Type: text/plain




|>  This is hard. It's probably not going to make it in the first
|>  release.  The simple first pass is to say "code signed by x,
|>  y, and z" can do whatever it wants.
|
|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. A statement to the effect of "is probably not going to
make it in the first release" means the following things:

- If we can, we will make it happen (in some form) in the first release.
We're just trying to set expectations realistically.

- We think that the ability to let applets have free reign is
useful,and since that is easier, we are certain to put it in the first
release.

- No matter what we do, we must address some very thorny issues of key
management and user trust model, so doing this will be useful. 

|Currently, the only safe way to run untrusted Java code is to not run it.   
|This probably isn't going to change (see cpunks archives for reasons).  If  
|Sun cannot prevent untrusted code from doing nasty things, how can they  
|prevent code empowered with certain capabilities from doing things they are  
|not certified to do?  It now seems that all the effort, time, and money to  
|move towards Java over another OO language was a waste in a way since it no  
|longer appears to have any security advantages.  Ignoring security, Java is  
|not a bad language at all, but it still has distinct disadvantages over some  
|of the possible alternatives (mainly immaturity, no dynamic message  
|invocation, interpreters still not ready for prime-time).

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.

Cheers,
-- Benjamin