Blake wrote:
On Mon, 26 Feb 2007 11:26:07 -0800, Paul D. Fernhout pdfernhout@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