E: Capability-Based Smart Contracts
"Hunter's Two Hundred Twenty-Second Rule: Culture achieved its peak when caffiene and chocolate were discovered. Everything since then was just unnecessary baroque embellishment." -- Jeff "Hunter" Jordan
A visitor to my office building, photo by Brian Fitzgerald:
# Well, I got the Pegasus inbox filter to work automatically. Must have had it defined incorrectly before. And I discovered that I don't need to import my Eudora mailboxes. Instead, I can just attach their folder, and read them right from the files that Eudora wrote. Kule. Pegasus doesn't grok as many message formats as Eudora, so I have to resort to the "raw" view sometimes, but mostly it works great. I can't find a keyboard shortcut for closing a window or reading new mail. I avoid the mouse whenever possible; too slow.
# Timothy Bancroft-Hinchey at Pravda - This is not Saddam - evidence that the man being paraded in front of the cameras is not the real Saddam Hussein. [grabbe]
The supposed Saddam was shown by an unconvincing Paul Bremer who declared "Ladies and Gentlemen, (pause) we got him!" The pause was telling, an unsaid "I am going to tell a lie". When the ex-President of Iraq's wife was taken to Qatar to see him, she burst out laughing and immediately said that this was not her husband. Had the Americans fallen for their own trap, or were a small group of Americans fooling the others?
...
Here was the mistake. As Mr. Vialls points out, the real Saddam Hussein had a fine set of teeth, completely even, in which the upper jaw closed over the lower (overbite). The figure paraded in court, as it is easy to see, has highly irregular lower teeth and a condition called "underbite", when the lower teeth close in front of the upper.
Touche. Dental records cannot lie. The set of teeth of the President of Iraq and the set of teeth of the man paraded before the cameras pretending to be Saddam Hussein are wholly and totally different.
# Ted the Tool - Guide to Lock Picking - theory, practice, exercises, and legalities. I've never tried picking locks. Never needed to. More details at Greg Miller's Guide to Lock Picking for Beginners. [clairefiles]
# Jeff Quinn at GunBlast - Ruger Mini-14 Ranch Rifle - Mr. Quinn reviews a classic. I've been tempted to get a Mini-30, but have heard too many discouraging words. Maybe I'll still do it, after I get my 1894P and a black powder rifle, that is. Only thing stopping me is that they're a bit pricey (around $650 last time I saw one for sale). Ruger's Carbine page says they retail for $695, or $770 for stainless. I could get two AKs for that price. [gunblast]
Over the years, I have owned a few Minis, and each one has proven to be absolutely reliable under all conditions. The design of the action is somewhat out in the open. When the gun cycles, it just slings off any dust, water, snow, ice, sand, mud, or other debris that might fall upon it. The Mini is also not as ammo sensitive as some other rifles. The gas system is very simple in design, with the gas impinging directly upon the operating rod. It is as reliable as a rock, unless allowed to rust, which I will explain. One problem that can occur with shooters who live in humid climates is that they will shoot the gun, then put it away with no lube on the gas system. If stored this way with the bolt fully closed, the gas system can rust, thereby sticking itself shut. Stored properly, it gives no trouble at all. In fact, I prefer to store the Mini with the bolt slightly open, and to treat the gas system with Militec lubricant.
...
...The accuracy of the Ranch Rifle matched that of other Minis that I have owned. It grouped regularly under one and one-half inches at one hundred yards with good ammunition from a good rest. I have never had a Mini-14 that would shoot as accurately as a target rifle, but the Mini was never built to be a target rifle. It is plenty accurate for its intended purpose, and adding a heavier barrel to enhance accuracy would detract from its excellent handling abilities. The Ranch Rifle did, however, exhibit excellent accuracy with Winchester Supreme 55 grain Ballistic Silvertip ammo, grouping between three-quarters to just under one inch with each three-shot group fired. The Ranch Rifle was also function tested with a variety of commercial .223 and military 5.56mm ammunition. Functioning was, as expected, perfect. The large extractor and fixed ejector sends brass flying swiftly to the right of the shooter...
...
The Mini-14 rifle series may not be as racy as the latest carbon fiber and space-age alloy European wonder weapons, but it is a strong, reliable, and handy little carbine that has been around for thirty years, and will be just as good of a rifle thirty years from now. It is fun, accurate, and easy to shoot, and I highly recommend it.
# Alexander Repenning - AgentSheets began life in Macintosh Common Lisp, but is now a Java application that can be used to create simulations and publish them as applets. Very neat. Don't miss the showcase of simulations. Glad to see the Dr. Repenning is being successful with this. I rediscovered it while perusing Robert Tolksdorf's Programming Languages for the Java Virtual Machine, always good for a few wows.
#
Mark Miller's
E Programming Language also looks interesting, incredibly
interesting. "E, the secure distributed pure-object platform and p2p
scripting language for writing Capability-based Smart
Contracts." I haven't read about capabilities since my
college days, over 25 years ago. The E zip file is only 3.9 megs, but
it came over a very slow pipe for me last night. Make sure to read
Smart Contracts. There is an
EeLanguage wiki page.
From Marc Stiegler's
The E Language in a Walnut:
- E has significant advantages compared to other popular programming languages for distributed computing. As one quick example of its power, E's promise-pipelining architecture ensures that deadlock cannot occur.
- E has dramatic advantages for secure distributed systems. All communication in E is strongly encrypted, transparently to the programmer. Capability-based security enables the concise composition of powerful patterns of interoperation, patterns that enable extensive cooperation even in the presence of severely limited trust. Excluding user interface code, a simple but effective peer-to-peer secure chat system has been written in less than 30 lines of code; no more lines of code were required to write a basic digital money bank server despite the severe security issues involved. When the time comes for a security inspection, capability security allows simple reachability analysis to exclude huge swaths of code because they cannot embody a threat. As a consequence, auditing a system for security becomes cost effective to an extent that is simply unimaginable with other approaches, as documented in the DarpaBrowser report. With E, it is straightforward to create systems that run across the Internet that are as secure and safe as if the entire system were running on a single computer in your basement.
- E can even enable the fearless yet powerful use of multi-party
partial-trust mobile code. "Mobile code" is just about anything
executable on your computer that you get from somewhere else. Every
time you turn on a word processor, play a game of Solitaire, or double
click on an email attachment, you are executing mobile code written by
someone you probably don't know and should not trust. Yet we give
Barbie Fashion Designer and Christmas Elf Bowling the full power to
read our most private documents, sell them on EBay to the highest
bidder, and then delete all your files. Our grandchildren will laugh
at how silly this was, yet today there is no choice. If Microsoft used
E instead of Visual Basic for its application language, Word and Excel
would not be vectors for attacks like the original Love Letter
virus. If all software were written in E, Klez and BackOrifice could
never have existed: indeed, the term "virus", so loved by the press
because it implies incurability, would never have been applied to
computing.
These qualities cannot be achieved with traditional security approaches. Do not expect the next release of Java, Windows, or Linux to fix the problem: the flaws in these systems lie at the heart of their architectures, unfixable without breaking upward compatibility, as we shall discuss in the chapter on Secure Distributed Programming. Of course, there is nothing to prevent people from advertising that they are releasing a new, upward compatible, totally-secure version of a product. Just don't jump off the Brooklyn Bridge to buy it.
Let us look at an example in a computing context, of how keys/capabilities would change security.
Consider the Love Bug virus, which has a modus operandi identical to the earlier Melissa virus. Each would come to you as an email message, read your address book, then send itself - using your email system, your email address, and your good reputation - to the people listed therein. You only had to make one easy-to-make mistake to cause this sequence: you had to run the executable file found as an attachment, sent (apparently) by someone you knew well and trusted fully.
Suppose your mail system was written in a capability-secure programming language. Suppose it responded to a double-click on an attachment by trying to run the attachment as an emaker. The attachment would have to request a capability for each special power it needed. So Melissa, upon starting up, would first find itself required to ask you, "Can I read your address book?" Since you received the message from a trusted friend, perhaps you would say yes - neither Melissa nor anything else can hurt you just by reading the file. But this would be an unusual request from an email message, and should reasonably set you on guard.
Next, Melissa would have to ask you, "Can I have a direct connection to the Internet?" At this point only the most naive user would fail to realize that this email message, no matter how strong the claim that it came from a friend, is up to no good purpose. You would say "No!"
And that would be the end of Melissa, Love Bug, and all the similar viruses yet to come. No fuss, no muss. They would never rate a mention in the news. Further discussion of locally running untrusted code as in this example can be found later under Mobile Code.
