From: Mike McNally <m5@vail.tivoli.com>
To: Andrew Loewenstern <andrew_loewenstern@il.us.swissbank.com>
Message Hash: b4c563e730d0729ab2e4718d6ccf499ac82219e2910dde3c3dc17e87176f1a3a
Message ID: <31B37DBA.5C8B@vail.tivoli.com>
Reply To: <199606031746.KAA01680@springbank.eng.sun.com>
UTC Datetime: 1996-06-04 05:26:22 UTC
Raw Date: Tue, 4 Jun 1996 13:26:22 +0800
From: Mike McNally <m5@vail.tivoli.com>
Date: Tue, 4 Jun 1996 13:26:22 +0800
To: Andrew Loewenstern <andrew_loewenstern@il.us.swissbank.com>
Subject: Re: Java Crypto API questions
In-Reply-To: <199606031746.KAA01680@springbank.eng.sun.com>
Message-ID: <31B37DBA.5C8B@vail.tivoli.com>
MIME-Version: 1.0
Content-Type: text/plain
Andrew Loewenstern wrote:
> > 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.
How can you do this currently? (With applets in browsers, I mean.)
> After all the hype about security, security models, and sandboxes we get
> signed applets that can do anything. What a let-down.
Well, it's not perfect, but I hold out the hope that real support for some
capability assignments can be provided by the time a serious infrastructure
of certificate authorities of some sort can develop.
Note also that this is not only a Sun issue; Netscape has to support it
all too. Currently, note that the HotJava browser already allows some
configuration to the Security Manager that Netscape doesn't.
> 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?
Huh? They're explicitly saying that they won't make any attempt to prevent
signed applets from doing anything they want to do, if you tell the thing
that you trust a particular certificate. Thus, you are now able to grant
complete trust to an applet with a given certificate. You can't readily
do that now.
This means that if you trust the certificate system itself, then allowing
an applet from Borland or Microsoft or IBM to do whatever it wants to your
machine is about the same risk as allowing a program on CD-ROM from Borland
or Microsoft or IBM to do whatever it wants to your machine.
> 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.
I think you need to explain this; it seems to have nothing to do with
the issue at hand.
> 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.
Based on the state of the Borland Java stuff I've seen, I wouldn't have
very high expectations in the Delphi department.
> 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..."
And for some applications (webish ones included or not) that's actually
a very good reason. Business is business.
______c_____________________________________________________________________
Mike M Nally * Tiv^H^H^H IBM * Austin TX * pain is inevitable
m5@tivoli.com * m101@io.com *
<URL:http://www.io.com/~m101> * suffering is optional
Return to June 1996
Return to “Mike McNally <m5@vail.tivoli.com>”