[E-Lang] E FAQ

[Mark S. Miller]

At 06:20 AM Wednesday 9/26/01, Jonathan A Rees wrote:

>As my little contribution to the effort, I've started an E FAQ. [...]
>
>  http://rosebud.mumble.net:8888/jar/e/faq.html

Very cool!  after another round of fleshing out, I'll link to it from the 
erights home page.

Btw, just curious, what happened to the original 
http://mumble.net/jar/e/faq.html ?

Some further answers and [notes towards answers]

>1.1. What is E?
>E is a programming language designed to make it easy to write
>                 distributed programs that are correct and secure.
>                 For more information, see E in a Walnut and the erights.org web site.

A fine short answer.

>1.2. Why is it called 'E'?

[What's good faq answer-length style?  If this is too long, please excerpt, 
or place elsewhere and link to it.  Thanks.]

Many people guess that it's an extension of the sequence 'B', 'C', etc.  
Other's have guessed that it's from the first letter of Electric 
Communities, or that it's for today's ubiquitous "e" as in "eMail".  But no.

(The following events happened at Electric Communities (EC) before I arrived. 
Perhaps someone on the list, or either of the Dougs (cc'ed on this message) 
can provide a more accurate account.)

At EC, Doug Crockford was playing around with letters and logos while Doug 
Barnes was creating the first prototype of the language that would become E. 
The language got to the point that it was clearly more than interesting, 
but it still needed a name.  Doug Crockford had just put together a cool 
graphic for the letter 'E' in Intellidraw (seen 
http://www.erights.org/images/small-logo.gif and 
http://www.erights.org/images/large-logo.jpg ), so he suggested something 
like "If you call it 'E', we can use this cool logo."

So the language was called E, the logo was used and was found good, and 
begat many a T-shirt.

This language, the one originally called 'E', was an extension of Java -- it 
approximately included Java as a sublanguage, in much the way C++ sort-of 
includes C as a sublanguage.  But this attempt at almost compatibility was 
thought to be worth it only if we could get Javasoft's cooperation.  EC was 
offering Javasoft, for free, an approach that could actually deliver on 
Javasoft's implied security promises, while preserving a large measure of 
compatibility.  We met the same NIH stonewall that I'd previously 
encountered while consulting (through a previous employer) to Sun Labs.

Without this cooperation, the pain of almost compatibility was no longer 
worth it.  The ideas of E split into EZ (a new distributed capability 
scripting language) and EZLib (the runtime library for implementing EZ, also 
usable directly from Java as a library).

Just as EZ/EZLib was getting interesting in its own right, EC, for business 
reasons one can argue about endlessly, turned away from EC Habitats (the 
social virtual reality system), E, EZ, and EZLib.  The great tragedy of 
ideas lost to intellectual property was about to be repeated, but then a 
miracle happened.

The EC board decided, without a fight, to open-source EZ and EZLib.  Since E 
was not to be open sourced as well, the name "EZ" was already taken, "E" had 
already gathered some name recognition, and "EZ" really was continuing the 
mission begun by "E"; it was decided to rename "E" to "Original-E", and to 
rename "EZ/EZLib" to "E/ELib".


>2.1. What is capability security?
>[To be answered - talk about naming, authorization, POLA.
>            Walnut deals with this.]

Jonathan, given your thesis, I suggest you take a stab at it.  I continue to 
think you explanation does better at motivating the definitional attributes 
of capability security than anything the rest of us has written.

In any case, my best attempt at a short definition is in the ode.  
Rearranging a bit, show the Granovetter diagram, give this link  
http://www.erights.org/elib/capability/ode/ode-capabilities.html , and say:

* Only Connectivity Begets Connectivity: How can Bob gain access to Carol?
  1) Connectivity by Introduction. Only when Alice
     a) already has a reference to Carol,
     b) already has a reference to Bob, and
     c) voluntarily decides to share with Bob her reference to Carol.
  2) Connectivity by Parenthood.
  3) Connectivity by Endowment.
  4) Connectivity by Initial Conditions.

* Absolute Encapsulation. 
* All Authority Accessed Only by References.

However, my best attempt at saying why is the Ode itself, which is way too 
long for a FAQ ;)


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

[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?".  That's why the MintMaker is potentially so important, 
together with the insightful failure earlier on e-lang to write a MintMaker 
using ACLs.  I propose that "write a MintMaker" may be for secure languages 
what "write recursive factorial" was for earlier symbolic or computational 
languages.  But maybe such an approach is overkill for a FAQ.]



>2.4. If capability security is such a good idea, why 
>             isn't it in wide use?
>[To be answered; acknowledge critics before shooting them down]

[Great question!  Norm may have the best historical perspective on this.  
Norm?]


>2.8. If capabilities can be sent over the network, doesn't that 
>          mean they're ultimately just strings (i.e. the characters that
>          get sent over the wire)?
>[To be answered.  Talk about sturdyrefs?]
>2.9. E seems to be vulnerable to denial of service attacks, 
>           such as long-running loops. What gives?
>[To be answered: there's nothing that can be done?]
>2.10. Is confinement really good for anything useful?
>[To be answered. Cf. especially the distinctions made by 
>http://www.erights.org/elib/capability/dist-confine.html]

[Actually, I'd meant to refer to those distinctions regarding 2.8 (as in the 
distinction between having and knowing).  Sorry for the confusion.]

[As for confinement, I like an analogy from Norm for thinking about it.  
Note to future readers, this is written in the days before pervasive wireless]

When I buy an HP calculator, I feel free to use it to enter in my company's 
financial data, even I'm working for an HP competitor.  I know, because of 
physical constraints, that the calculator is not communicating my secrets 
back to HP.  If instead I use a spreadsheet program on a 
Windows/Mac/Unix/Linux PC, I have no such assurance.  (For those who believe 
program vendors -- or at least reputable ones -- would never stoop so low, 
see the tale of software from RealNetworks, Netscape, or NetZip at 
http://grc.com/downloaders.htm ).

If, instead, you were installing a malicious spreadsheet caplet, even one 
written by RealNetworks, but you granted it no authority that enabled it to 
escape confinement, then you could be confident that you could give it your 
financial secrets.  It may give you bad answers, but it can only leak your 
secrets to the extent it can wall-bang.

[The above is a bad example because the possibility of wall-banging makes it 
too weak.  Info can be leaked, but authority can really be confined.  What's 
a nice motivating case for confining authority?]


        Cheers,
        --MarkM