[E-Lang] E FAQ

[Jonathan S. Shapiro]

I agree in spirit with what Steven Owens has suggested, and his wording is
certainly less inflammatory than the original.

That said, there is something his proposed replacement gets wrong, and I
think we should consider how we might correct it. The particular words I
disagree with are:

> However, java's general security mechanism -
> the sandbox, the java security manager and security policy - is
> complicated and awkward to use.

The problem is much worse than a matter of mere awkwardness. The awkwardness
is certainly real, and definitely a problem, but this should be a secondary
point in the paragraph. An important statement to make is something like the
following:


Java's general security tools - the sandbox and the Java security manager -
are known to have a number of design flaws. Equally important, they are not
backed by any rigorous security model that would give us any basis for
confidence in either their comprehensiveness or their correctness. Even if
the implementation were completely free of design flaws and bugs, there is
no reason to believe *in principle* that the Java security model for
applications works. It has been repeatedly shown in security policy research
that security policies are easy to state and security mechanisms easy to
build, but successfully enforcing the desired policies using the available
mechanisms is unusual. Designing mechanisms that are flexible, composable,
and effective is known (both practically and mathematically) to be
exceptionally difficult. Until the claims made about Java's security
mechanisms (or indeed, *any* security mechanism in *any* language or system)
are substantiated with public, rigorous verifications, these claims should
be treated as unproven assertions and treated with considerable skepticism.

There are quite a number of basic security flaws in the Java runtime library
that can be fixed only by violating backwards compatibility. There are also
flaws in the core object specifications (every object has a mutex). Given
that these flaws are known, and that fixing them would break most existing
Java programs and libraries, we are skeptical that the Java environment will
ever come to provide meaningful protections between two applications running
in the same virtual machine.

That being said, it is important to recognize the importance and value of
safe languages. Java is in many regards quite a good application language,
and the ability to run programs in distinct JVMs really does provide a
degree of isolation that is not readily available in most language runtime
environments. For many of the important Java target applications the runtime
startup overhead of "one program, one JVM" is prohibitive, which may be why
this issue has not received much promotion by Javasoft.