1996-06-04 - Re: Java Crypto API questions

Header Data

From: Andrew Loewenstern <andrew_loewenstern@il.us.swissbank.com>
To: br@doppio.Eng.Sun.COM (Benjamin Renaud)
Message Hash: a03cda57c0daebd137ed65563022886ab7eb2980e2259faa951934081118184c
Message ID: <9606032248.AA00623@ch1d157nwk>
Reply To: <199606031746.KAA01680@springbank.eng.sun.com>
UTC Datetime: 1996-06-04 03:48:28 UTC
Raw Date: Tue, 4 Jun 1996 11:48:28 +0800

Raw message

From: Andrew Loewenstern <andrew_loewenstern@il.us.swissbank.com>
Date: Tue, 4 Jun 1996 11:48:28 +0800
To: br@doppio.Eng.Sun.COM (Benjamin Renaud)
Subject: Re: Java Crypto API questions
In-Reply-To: <199606031746.KAA01680@springbank.eng.sun.com>
Message-ID: <9606032248.AA00623@ch1d157nwk>
MIME-Version: 1.0
Content-Type: text/plain


Benjamin Renaud br@doppio.eng.sun.com writes:
>  Policies are statements like:
>
>  "code endorsed by any one of the following signatures (say
>  three of my friends) can access the public part of my file
>  system"
>
>  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.

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

I wonder if Borland realizes that instead of putting so much time, effort,  
and money into someone else's product, Java, they could have just implemented  
signed Delphi code and gotten basically the same thing.  I guess they didn't  
think of it in time.


You have to hand it to Sun/JavaSoft's marketing team, though.  While others  
have tried, few have been so successful at creating an "industry standard"  
from nothing.  Indeed, the only reason left to use Java is "because everyone  
else is into it..."


andrew





Thread