> From: Lex Spoon [mailto:lex at cc.gatech.edu]
> It's easy to make a modified compiler which removes booboos 
> like this. 
> Things to remove:
> 
> 	1. <...> primitives
> 	2. thisContext
> 	3. access to the full Smalltalk dictionary

Having done something this to nail down VisualWorks...

4. Ability to modify the Compiler.
5. Ability to create your own Compiler.
6. Ability to instantiate arbitrary classes and therefore create your own
methods and fill 'em with bytecodes.
7. Ability to become: on methods to swap 'em for others that you've created
and are waiting in the wings.
8. Debug primitives such as instVarAt:put:

It is *not* easy.  Anything but.  I was trying to do the more restricted
form of preventing users seeing source code to which they didn't have
access; that was messy enough.  It's a whole lot harder when you have ways
of generating and dumping arbitrary bytecodes into your system.

Given the choice, I'd certainly go for removing 'dangerous' primitives ---
and ensuring that no part of the remaining run-time system used those
primitives, which could be fun.

> But in
> return, you get a much more flexible system.  Your proxies can invoke
> arbitrary Smalltalk code as they make their decisions.  You security
> policies can be implemented in Smalltalk code instead of C, 
> so that you
> can easily do complicated things like consulting network 
> databases. 

I agree that it is more flexible, but it is also *much* harder to verify.
Crackers are still able to get at functionality provided they can find an
appropriately tortuous route through the proxies.  I'd be much happier
running an unknown Squeaklet on a VM with its I/O primitives removed or
crippled than I would on a fully-functional VM with image-level
capabilities.

		- Peter

P.S. Should I admit I've been on the software cracking side in my time?