>He indicated that as security professionals,
>it is our job to build systems that protect
>the user.
Just a tangential thought along this line. Should we discriminate between security and safety? I'd put "protecting users from themselves" in the safety category, and construct devices accordingly. A mechanical blocking mechanism on a paper shredder, for example: we know it's not secure (the user can always unscrew the brackets and remove it), but it does serve as a handy safety mechanism.
One outcome of the E capabilities literature is that you shouldn't be led down the path of trying to "secure" that paper shredder - "hey, what if we used hexagonal screws instead of phillips screws" ... "and in addition, we can put bracing around the screw hole that'll require a special angled driver to reach in", ... etc., etc., This leads us down a path of building up a more and more complex shredder that just frustrates the user and is more prone to break. And doesn't protect us from the wily shredder hacker, who can, and will, circumvent these blocks in his quest to ... stick his own hand in the shredder. But, as a matter of safety, these devices make sense.
just a thought,
Kevin Lacobie