From: Blake Coverett <blake@bcdev.com>
To: “‘Marianne Mueller’” <mrm@netcom.com>
Message Hash: 868c2f90f2049799adf884d98c106b475c2ffc817eea13e1b199de597659e0b5
Message ID: <01BB39CB.CF21E530@bcdev.com>
Reply To: N/A
UTC Datetime: 1996-05-04 23:59:24 UTC
Raw Date: Sun, 5 May 1996 07:59:24 +0800
From: Blake Coverett <blake@bcdev.com>
Date: Sun, 5 May 1996 07:59:24 +0800
To: "'Marianne Mueller'" <mrm@netcom.com>
Subject: RE: Calling other code in Java applications and applets
Message-ID: <01BB39CB.CF21E530@bcdev.com>
MIME-Version: 1.0
Content-Type: text/plain
> 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.
I was right in the first message... it is a reputation thing. We don't
disagree on any of the fact here, just on their implications.
I see this from the point of view of the author of these native methods,
cypherpunk still do write code sometimes. From that point of view
where is the difference between calling my native code methods and
calling the java.awt.*, or netscape.* methods that are native code? Yes,
either can do anything they want, irregardless of the SecurityManager.
For J. Random User on the net, Sun/Netscape's reputations are
fairly strong and mine is non-existent. For the corporate IS folks to
whom I contract this situation is reversed. (Despite impressive IPOs
I still get a lot of friction about 'programs downloaded from the net'.)
-Blake
Return to May 1996
Return to “Blake Coverett <blake@bcdev.com>”
1996-05-04 (Sun, 5 May 1996 07:59:24 +0800) - RE: Calling other code in Java applications and applets - Blake Coverett <blake@bcdev.com>