"Inteligent" Shrink?

Andreas Raab andreas.raab at gmx.de
Mon Feb 26 20:27:03 UTC 2007


Blake wrote:
> On Mon, 26 Feb 2007 11:26:07 -0800, Paul D. Fernhout 
> <pdfernhout at kurtz-fernhout.com> wrote:
> 
>> Why take a perfectly working application and start potentially 
>> introducing all sorts of random errors into it at the last minute just 
>> to save a bit of storage space and network bandwidth (especially these 
>> days)?
> 
> Security?

There is hardly any goal for which shrinking is a more decidedly 
unsuited approach than security. While it may be possible to plug a few 
holes that way (which is probably what you were thinking, e.g., "remove 
the dangerous code" somehow) a truly secure system is one that never had 
that dangerous code in the first place, e.g., was built without it.

The main problem with shrinking is that it's usually not predictable, 
e.g., driven by some sort of heuristics like messages not sent anywhere, 
and unless you unload entire modules (in which case shrinking is 
effectively equivalent to building the system from scratch [*1]) a 
non-predictable result is about the worst thing one can imagine for a 
secure system.

[*1] Except for side-effects which is another reason for building it 
from scratch instead of shrinking - that "dangerous" code may leave 
artifacts in the image even after it has been unloaded.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list