[E-Lang] E FAQ

[Mark S. Miller]

At 09:53 AM 10/8/2001 Monday, Steven J. Owens wrote:
>> [This may also be a good opportunity to change the terms of the debate from 
>> "is it secure?" to "what patterns of cooperation without vulnerability does 
>> it support?".
>
>     This is something I'd really like to see.  Specifically, I'd like
>to see a brief overview of each pattern of cooperation, discussed in
>concrete terms, followed by a discussion of how to implement such a
>pattern in Java - and where and why it can't be done.  Maybe discuss
>it at a higher level - talk about patterns of cooperation between
>enterprise or network level java applications, instead of between
>components of a single desktop application.

I agree.  This is precisely the kind of thing we need.  Oh, so many things 
to do!

There is a start on such a taxonomy in Walnut at 
http://www.skyhunter.com/marcs/ewalnut.html#SEC45 .  In addition, I propose 
that the MintMaker from the Ode 
http://www.erights.org/elib/capability/ode/ode-capabilities.html#simple-money
be used as a first test of secure language designs in much the way 
recursive factorial is used to test symbolic language designs.  There was a 
good discussion on e-lang a while back (need link) attempting to reproduce 
the functionality of the MintMaker in a hypothetical ACL system.  I strongly 
suspect the negative result would apply directly to Java, but I don't 
remember if Java specifically was examined.


At 08:42 AM 10/9/2001 Tuesday, Karp, Alan wrote:
>We all know that there are problems with Java security, but some folks will
>say that the flaws are fixable.  We don't want to get into a "he said, she
>said".  
>
>The flaws in Java security don't go to the essential point about E.  As I
>see it, Java security was designed to enable safe use of downloaded code.  E
>is designed to allow complex patterns of cooperation.  I think that is the
>point to be made in the FAQ.  That way, no one is attacking Java.  All
>that's being said is that Java and E were designed to address different
>problems.  Implicit is the fact that E is solving the important problem.

I really have no strong opinion about whether or not we should be seen as 
attacking Java.  (Actually, I have both strong opinions, so at the moment I 
have no net strong opinion.)

Other than that, I agree wholeheartedly with Alan.  I have had the following 
form of argument with people more times than I care to remember:

Me: "Java (or something else) isn't secure."

Them: "Then demonstrate a breach of its security, the way others did with 
(earlier) Netscape browsers."

Me: "I'm not claiming I can break its security."

Them: "Then isn't it secure?"

The following is not text I'm suggesting go into the FAQ, though some of it 
may be useful.  Rather, it's just some thoughts stimulated by the topic.


We absolutely must escape from "We're secure and they're not."  The sense in 
which Java may or may not be secure is the sense examined by the Princeton 
group, Vijay, and others that tried to break the verifier.  Or again, the 
Princeton group, in trying to break out of restrictions imposed by the 
Applet ClassLoader & SecurityManager.  These kinds of investigations -- 
seeing whether safety is preserved -- are important, and Java, by going 
through intense public scrutiny and fixing many of these kinds of flaws, is 
probably now more solid in this regard than is E.

Instead, our criticism of Java, and our comparative rationale for E, is at a 
whole other level.  The problem Java set out to solve is perimeter security 
in the context of mobile code.  This problem is also solved by buying a new 
machine for each applet, and running that machine in a closed room with no 
I/O devices.  Admittedly, that would be expensive.  The problem would also 
be solved by an operating system in which you could configure a process to 
run such that no system calls (or other traps) caused any action outside the 
process, and no other process could effect that process.

The essential ingredient for perimeter security is impenetrable boundaries 
-- Object encapsulation, as enforced by Java's verifier, machine boundaries, 
or MMU-imposed address space boundaries.  Perimeter security is then 
necessary for building a security architecture.  All three of these are 
respectable implementations of perimeter security on top of which an 
architecture can be built.  The job of an architecture is to allow these 
separated components to be able to interact usefully with the outside world 
and each other, but without threatening each other's integrity or interests. 
This is support for cooperation without vulnerability.  What kinds of 
interaction can be supported while preserving safety?  Different 
architectures impose vastly different costs as the price of preserving 
safety.

Applets do in fact interact with the world outside of themselves, but in a 
peculiar, ad hoc, and broken fashion that is symptomatic of a bad architecture 
or no architecture.  For an example (due to MarcS), a spreadsheet applet may 
communicate the financials you enter back to it's originating server, but it 
can't save it to a file on to your own disk.  In Java, the price of safety is 
too high, and as a result, applets are universally thought to be lame, and 
(despite a level of hype the gods would envy) are mostly unused.

It is important to note that, by the goals Javasoft initially set out to 
achieve http://www.eros-os.org/pipermail/e-lang/2001-January/004030.html , 
this state of affairs should be considered a success.

(Whether or not we should antagonize Javasoft in the FAQ, I feel free to do 
so on e-lang.)


        Cheers,
        --MarkM