On Sat, Feb 08, 2003 at 11:02:50AM -0800, Mark S. Miller wrote:
Once you have the right inabilities (as in my proposal that we should specify a capability secure subset of ANSI Smalltalk), then you may have security, but you don't yet have a useful system. As you add abilities back to such a system, but in a way that preserves the crucial inabilities, you make the system more usable without losing its security.
I think that, by doing this, we can eventually build back up to something close to the level of functionality of current Squeak. But the result will not be compatible. You cannot add inabilities to a system the way you add a new package. New inabilities means that some old code must break.
One of the big problems that needs to be addressed is the social one. About two years ago, the Squeak community began an ill-fated attempt to retrofit modularity into Squeak. The resulting design failed to generate the necessary buy-in by the average Squeak hacker. The current SqueakMap work is an alternate attempt at modularity that takes less ambitious steps forward, and has been quite successful so far.
Evolving Squeak to meet the requirements for "level 4" security promises to be even more disruptive to the average programmer. On the other hand, it is my belief that this level of security is necessary for Squeak/Croquet to achieve their dream of revolutionizing personal computing.
So, how can we address this problem? Mark, you mentioned a 2-vm design earlier; there would be a separate VM for Squeak-E within the regular Squeak VM. I don't completely understand how this would work. The following is an attempt to clarify the possibilities of the 2-vm approach.
Assume that Collection and all of its subclasses have been made capability-secure. These classes are, of course, used widely throughout Squeak. Can these secured classes be transparently used by insecure code? From your writings, I gather that they can. How might this work?
This process -- removing everything that doesn't follow capability discipline, followed by adding back in new APIs that provide similar functionality in a capability-compatible way -- is a kind of refactoring, though a much more violent case then we normally encounter. A great example is Lex's ObjectInspector in the Island's work. It moves the reflective messages from the objects themselves, where any client of the object could invoke them, and puts them instead on ObjectInspector, which can be given only to those that should indeed be authorized to break the encapsulation of these objects. (The Brand system explained earlier enables the issue of "which objects" to be dealt with in a finer-grained fashion, but that's not relevant to the points I make here.)
<snip>
In the kind of massive refactoring we'd need to get language-based security, not only can't we be upwards compatible, we can't necessarily retain all the features we'd like.
Can you give some concrete examples?
Our likes evolved without constraint of security. Some things we like may be incompatible with security. Or it may be years before we invent the reconciliation that allows us to revive some form of a feature we like without breaking security (as in my explanation of the Safra/Shapiro virtually nested virtual machines notion).
In the meantime, we have to break the feature, not security. If we proceed the other way around, we'll never be secure. This means it'll go though a phase where it may be Smalltalk-like to many eyes, but where the cognoscenti may indeed judge that "it isn't going to be Smalltalk". If you're not willing to go through such a phase, don't bite off language-based security.
The problem isn't "keeping it Smalltalk". I believe that you noted that Smalltalk is more of a philosophy than a particular set of language features. So, if the end result is a better language, I don't think that people will be too concerned if we end up with Smalltalk-04 (or whatever).
The problem is managing the pain along the way. Most Squeak developers won't actively be involved in developing Squeak-E. Take me for instance: I'm busy trying to get my Ph.D. in computer animation, and my wife and I want to get the heck out of Atlanta ASAP. I'm very interested in Squeak-E, and would like to incrementally modify my code to fix whatever breaks as APIs are tamed. But I _need_ the programming environment that I am accustomed to; if Squeak-E can't support the debugger and other development tools, then I fear that the Squeak community will not follow.
Traits, continuations and my eventual sending redirectors are other examples where either dynamic scoping or system openness are crucial to allow us the facility.
Traits looks very cool, but I don't really understand them yet.
Allow me to correct myself. Traits looks *very* cool!
They sure do!
<snip>
Joshua