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

Dean Tribble tribble at e-dean.com
Sat Feb 8 13:19:06 CET 2003


This is a response to some comments about the importance of openness to 
Smalltalk.

One of the reasons I have not spent more time working on squeak and porting 
older Smalltalk libraries and tools to Squeak is a confusion about openness 
and malleability.

Openness:

One of the most wonderful things about a Smalltalk environment is that it 
is open to inspection, modification, and extension by the developer.  This 
might be the single most important thing about Smalltalk.

But it is *not* at odds with security.  What is at odds with security is 
confounding open-to-the-developer and 
open-to-any-program-that-happens-to-be-nearby.  I would like a Smalltalk 
system that is open to *me* when it is running on my machine, but in which 
the programs are not exposed to *each other*.  (Indeed systems that try to 
prevent me from seeing or manipulating things on *my* machine make me very 
angry! :-)

As MarkM says, getting back to the sense of *the developer* being able to 
change anything while still preserving capability security could be 
challenging.  But it's a lot easier to get to a place where programs must 
follow rules with each other, but development tools can get the access they 
need easily.  The general pattern is to replace primitives for getting 
inappropriate access (e.g., instVarAt) with "closely-held" capabilities: 
capabilities that are available only to a few programs, which ensure that 
their use does not violate capability discipline or system integrity.

Let's look at instVarAt: for example.  It is primarily there to support 
meta-level tools like inspecting and debugging.  These are almost always 
tools for developers, not programs.  Replace instVarAt primitives with a 
primitive capability that is closely held by the development tools.  The 
developer's tools then use that capability to look inside any 
object.  Normal programs don't have access to the capability, and so they 
cannot violate arbitrary object encapsulation.  The developer can decide to 
make a new service that has that capability (e.g., an object serializer for 
rewriting the Smalltalk image in a different format), but again that 
doesn't mean the authority is available to the Web server.

Malleability:

Another important facet of Smalltalk's openness is malleability, the fact 
that a programmer can change anything in the environment.  Too often, 
people confuse this with increasing flexibility in arbitrary dimensions, 
and removing all barriers and modularity.  As a result, it often seems at 
odds with security.  First, I'll give some examples of what I consider 
bogus malleability in Smalltalk;  the basic theme is that Juntas are a 
symptom, not a solution.

- When I'm refactoring the Browser, I don't want the browser I'm currently 
using to break.  I want to create a new version of the Browser, then try it.

- I might want to (and have!) develop an entirely new user-interface 
framework, possibly starting from the current one, without breaking my 
development environment as I go.

- At a non-gui level, I've changed the way that numbers decide on 
coercions, without breaking the system.

Doing that as Juntas just seems pointless and silly; I should be able to 
produce a new system without breaking the old version.  I want complete 
control, without having my entire environment feel like it is made of mud 
because it keeps changing out from under me (and yes, I'm exaggerating a 
little for effect).

I guess my point here is that one can have a system that is entirely 
malleable to the developer, with the ability to add structured hooks 
(closely held) to apply that malleability to new tools or techniques, 
without having arbitrary malleability be a common element in the 
programming environment.

So the final claim is that Squeak-E could have the familiarity with 
Smalltalk, with the differences only showing up for people that "open up 
the hood", but those people will just open the hood in a slightly different 
but still easy to understand place, and have all the power they could 
want.  This seems like a useful intermediate target (in the spectrum of 
security targets) that would also be comfortable to the Smalltalk community.

Comments?



More information about the Squeak-e mailing list