[5079] in java-interest
Re: Netscape security => lame applets
daemon@ATHENA.MIT.EDU (nathanw@MIT.EDU)
Sun Jan 28 13:46:53 1996
From: nathanw@MIT.EDU
Date: Sun, 28 Jan 96 12:29:34 -0500
To: Cay Horstmann <horstman@jupiter.SJSU.EDU>
Cc: java-interest@java.sun.com
In-Reply-To: [5062]
Cay Horstmann <horstman@jupiter.SJSU.EDU> writes on
Sat, 27 Jan 1996 10:51:05 -0800
> The implication is that you cannot present your applet users any data
> except for files that you currently have available on the same file system
> that serves the applet.
... stuff deleted ...
> The TOTAL IDIOCY here is that the ambient browser can read all that data,
> but your applet can't.
... stuff deleted ...
> I guess if you view applets as a means of conveyance for nervous text and
> tumbling molars, then this isn't a big deal. But if you viewed applets as
> something that can do MORE than HTML and CGI, then this is pretty
> depressing. Or am I missing something important?
It's an important part of the security model that an applet
not be allowed arbitrary network and file system access. The idea is
that since applets are loaded and executed automatically, they must be
constrained to prevent malicious applets from abusing the network or
file system. A more sophisticated code distribution model could allow
for loaded applets to have different levels of trust (via key-signed
code or some such) and corresponding levels of system priveleges.
I think you are confusing applet functionality with Java
functionality, though. For server-side systems, or automated web
indexing, you don't want to use the untrusted applet interface; you
want to create a standalone application that you can endow with
whatever priveleges you see fit. Use of Java is not limited to the
narrow world of applets; the system has much more interesting
possibilites.
- Nathan <nathanw@mit.edu>
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
