[Squeak-e] Comments on Anthony's "...Shared Smalltalk"

[Joshua 'Schwa' Gargus]

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