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

[Mark S. Miller]

I just realized that Dean's message may not have been accepted by the 
mailing list. Apologies if you see this twice.


>X-Sender: agorics at postoffice.pacbell.net
>X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
>Date: Sat, 08 Feb 2003 13:19:06 -0800
>To: "Mark S. Miller" <markm at caplet.com>
>From: Dean Tribble <tribble at e-dean.com>
>Subject: RE: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
>Cc: Squeak-E - a capability-secure Squeak <squeak-e at lists.squeakfoundation.org>
>
>
>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?
>
>
>
>  


----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM