[E-Lang] E FAQ

[Steven J. Owens]

Hi,

>> 2.3. I thought Java was secure.  Isn't it?
>
>> Sun claims that 'right from the beginning, the Java platform was
>> designed to run programs securely on networks'. Java takes many
>> steps in the direction of language-based security, such as pointer
>> safety and garbage collection.  However, as explained in E in a
>> Walnut's 'Capability security' section, Java security is based on
>> identities of principals, not on keys, and is so complicated that
>> no one uses it nontrivially. It may work for confining applets, but
>> not for more sophisticated patterns of cooperation. For an example
>> of Java's pervasive inattention to security, see the discussion in
>> the same section of how Java's ReadStream class fails to be secure.

     Uhm... are you deliberately trying to antagonise to the java
folks?  I thought part of the idea of having E implemented on Java was
to co-opt the java programmers.  Along those lines, this might be
phrased a little more constructively, maybe something like:

While Java is somewhat more secure than many other languages, it is
not yet really secure.(*) Java has pointer safety and garbage
collection as well other important beginning steps in the direction of
language-based security.  However, java's general security mechanism -
the sandbox, the java security manager and security policy - is
complicated and awkward to use.  Security is always a trade-off; does
the reduction in risk justify the the extra development time?
Security that is too difficult to use is not security.

Java doesn't provide the programmer with the built-in, sophisticated
security concepts that E has.  Java's security model is based on
identities of principals instead of keys.  E's security model is based
on capabilities; capabilities give you the tools to build truly secure
applications.  More than that, a language with capabilities built
right into it naturally leads you towards building more secure
applications.  An inherently capability-based language like E lets you
think, design and develop with security in mind, instead of changing
gears to think about security implications.

(* To be specific, there is no such thing as "really secure" -
security is not a boolean value, it's a scalar value.  The question is
never "is it secure?", the question is "is it secure enough?" See
 [some other FAQ or document] for a discussion of this.)

 
> [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.

     While I'm adding things to the wish list, I'd really like to see
two concrete things.  A discussion of how E is actually implemented at
the present time.  And a good, real-world example program in java,
rewritten in E.  Maybe even rewritten several times, each time taking
it more in the E direction, illuminating more of E's features and
explaining more of the security vulnerabilities eliminated.  I realize
that these wouldn't really belong in a FAQ, but I think they'd be
crucial in speeding adoption of E.

     I'm not an academic, nor am I a language designer.  To be honest,
I often feel out of my depth when reading e-lang traffic.  I've picked
up a valuable amount of the security mindset just by following the
discussions here, but I've been wading through the E website (and E In
A Walnut) repeatedly over the last 12 months.  Each time I learn a
little more.  Each time I get a little further.  Each time I
eventually get bogged down in abstractions and meta-meta-concepts.  To
understand capabilities you have to understand patterns of
cooperation.  To understand patterns of cooperation you have to
understand The Confinement Problem.  To understand The Confinement
Problem you have to understand The Confused Deputy problem.  Etc, ad
nauseam.  I keep trying, but I keep thinking there's gotta be a better
way.

Steven J. Owens
puff@darksleep.com