Blake wrote:
> On Mon, 26 Feb 2007 12:27:03 -0800, Andreas Raab <andreas.raab at gmx.de> 
> wrote:
> 
>> 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.
> 
> As I said to Paul, I thought the discussion had already remoevd 
> building-from-scratch as an option, and the question was, "Given the 
> vast bandwidth and disk space we all have, why bother with shrinking at 
> all?"

And the above is the answer: If security is your goal, don't bother 
shrinking. It's not worth it. Rather than shrinking, rethink your lines 
of defense and which threat model you need to defend against and how. 
Which can of course include the removal of certain methods or classes 
but you are then no longer randomly "shrinking" but rather performing an 
explicit process of securing your image against attacks which has much 
more in common with building it up, since it has explicit goals and 
isn't one of them "oh, lemme see if I can just remove this class" 
approaches.

[BTW, I think there is some confusion with various posters what 
"shrinking" means. For me it is the process of applying a heuristic to 
determine which classes and methods can be removed. In other words, it 
is NOT a process where a developer decides explicitly what gets removed, 
which is why there is a certain amount of unpredictability and 
randomness to it].

Cheers,
   - Andreas