[2988] in java-interest
Re: Dynamic libraries, security, and extensibility
daemon@ATHENA.MIT.EDU (Michael St. Hippolyte)
Wed Oct 25 16:29:19 1995
Date: Wed, 25 Oct 1995 11:27:29 -0400
To: java-interest@java.Eng.Sun.COM
From: mash@interport.net (Michael St. Hippolyte)
From ser@jersey.uoregon.edu:
>
>I am aware that DLLs are accessable from applications. I have also seen alpha
>applets which access DLLs which you are required to install yourself on your
>system. I am not certain that this functionality is available in the beta
>release.
I've heard that pre-beta Java supports DLLs, but Netscape 2.0's
implementation does not. (I won't be able to find out for myself until the
Win NT version of the JDK comes out). I would love to stand corrected on this.
> We are still left,
>then, with the security issue: Java can have no control over the behavior of
>native code, and so to be secure, should not allow access to native code from
>applets. I am not neccessarily supporting this dogma, but it seems to be a
>major issue in the success of Java.
>
>- --- SER
>
There are two security issues: the security of the pipe and the
trustworthiness of the originator. Even if you could make the pipe 100%
secure, there's no way to prevent an evil-minded Java programmer from
causing problems for users of his/her applets. Doing things like preventing
native code, local file access, etc. only stops some of the more obvious
ways of causing damage. If a Java applet is providing real-time financial
data, for instance, there's simply no way the Java runtime can guarantee
that the applet is not monkeying with the numbers.
There is no escaping the need for basic human trust between the applet
provider and user. By giving users a false sense of security, denying
access to native code may actually exacerbate security problems.
Michael St. Hippolyte
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
