1996-05-04 - Re: Calling other code in Java applications and applets

Header Data

From: mrm@netcom.com (Marianne Mueller)
To: blake@bcdev.com (Blake Coverett)
Message Hash: 8fe859ddc19a740f40895fe9d99b08dfd04719c9d62df55ea9686f7bf0d9861e
Message ID: <199605041734.KAA24761@netcom20.netcom.com>
Reply To: <01BB397D.395BE6C0@bcdev.com>
UTC Datetime: 1996-05-04 23:24:48 UTC
Raw Date: Sun, 5 May 1996 07:24:48 +0800

Raw message

From: mrm@netcom.com (Marianne Mueller)
Date: Sun, 5 May 1996 07:24:48 +0800
To: blake@bcdev.com (Blake Coverett)
Subject: Re: Calling other code in Java applications and applets
In-Reply-To: <01BB397D.395BE6C0@bcdev.com>
Message-ID: <199605041734.KAA24761@netcom20.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


No that wasn't  my point (that the native code is less
trustworthy than the Java runtime.)    My point was just
that any security measures that restrict applets do not restrict
anything that an applet causes to happen via a native method. 

For example one security restriction is that applets aren't allowed
to read files.   If an applet calls a native method then that native
method can read any files it wants.    I'm talking about the model,
not about the quality of implementation.     I'm not saying it's 
a bad or untrustworthy thing to do (call native methods), I just
thought it was worthwhile to point out that once you call a DLL 
from an applet, you have effectively chosen to disable the application
level SecurityManager.  It's your call as to whether this is a problem
or not.   

Marianne





Thread