[E-Lang] Pet Extensions and such (was: what is good about E?)
Chris Hibbert
hibbert@netcom.com
Wed, 25 Jul 2001 09:48:07 -0700
MarkM, you left out one of the alternative approaches to all this that
I've talked about for a while. I always thought that the people who
designed the Java applet secure interface missed a great opportunity to
solve this problem.
When downloading a Java applet, the current security rules enforced by
the JVM restrict the applet to one particular subset of Java
functionality that is believed to be safe. From the beginning it was
obvious that there wouldn't be a one-size-fits-all selection of
functionality that would serve all purposes. It was intended from the
beginning that Java applets be able to perform tasks including solitaire
games, networked games, home finance, e-commerce, chat and more. These
tasks have overlapping requirements, and the union of their requirements
can't be made safe.
They should have designed a few bundles of capabilities, each of which
would be relatively safe to hand out to any applet that asked. Any
applet that was willing to request a standard bundle would be granted it
most of the time. (Some people would turn off the bundle that allowed
multi-player, real-time, networked games. Others wouldn't have allowed
any applets access to their wallet, disabling a standard e-commerce
bundles.) Applets with unusual requirements would have to ask the user
in a more detailed dialogue. Reviewers would have to explain either
that the particular bundle of resources requested was safe or that the
manufacturer had demonstrated enough reliability that it made sense to
grant unsafe access to their product.
A network game bundle would include a certain amount of (isolated) disk
space, a (large) slice of the CPU, the ability to communicate with the
outside world, and a large window on the screen. There wouldn't be any
way to read other files off the disk, to preempt the user from turning
off the applet, or to draw outside the window.
A finance applet would be able to read the user's quicken file, but not
write it, make new files up to a certain size, and consult a few public
web sites. It wouldn't be able to change the user's data, or report
back to the site it came from.
It's not obvious to me what the particular interface is to configuring a
home stereo with this kind of interface, but it seems likely that
someone could come up with an approach in this style. Installing a new
application on the desktop seems completely analogous. Ken's "typical"
and "minimal" would be replaced by particular standard bundles.
"custom" installation would require a dialogue with the user, but would
allow the applet access to more resources.
Chris