Name: jn10789 Date: 03/11/99


The java security mechanisms in 1.2 do not seem to handle
the following problem directly. Let us assume that I run an
applet or application that I do not completely trust. I
am willing to give the software permission to create,
read, or write specific files or files in specific directories.
I can use the security mechanisms to do this for specific
files or directories, using wildcarding, if I know enough in
advance, but I cannot do this at runtime. An example might
be a web-page installer that would create a directory tree
from a zip file, customizing the files in some way, but with
the target directory known only when the installer runs.

This could be handled better from the end-user's perspective
using one or both of two mechanisms.

One would be to extend
Swing components to provide dialog boxes to open or write files
with the file-open operation included in the component. Since
the component is part of the JDK, it would not be necessary to
trust whomever provided the applet or application.

The second would be to provide some sort of security request
as parameters to an applet, or as part of the manefest file
in a jar archive. A browser or javarunner would then look
at this information and grant the appropriate permissions
(after asking the user) before allowing the applet or
application to run.

If provided, this would enable the safe use of applications
obtained over the net. As it stands now, I cannot run
an applet that implements a spreadsheet, with the spreadsheet
data stored on my file system, and where I specifically give
the applet the file to read or write, without going to
special efforts to set up the appropriate permissions for
that applet, including predicting where I will want to place
the files the applet uses.

While the security mechanisms in Java 1.2 can allow the above
to be implemented, the classes that do this need to be
standardized before users will be comfortable.
(Review ID: 54743)
======================================================================