Toolkits, Bugs, and Interfaces

[bart@netcom.com (Harry Bartholomew)]

    Ten days ago Tim May ended a post on Toolkits:
    "For digital money to succeed, there had better not be flaws and
    loopholes that allow attackers to drain your money away or to cause
    confusion and doubt amongst your customers!..."

    I think near certainty of correct function is needed for all
    cryptographic software to find acceptance with the general public.
    Of the the aspects needed, algorithmic correctness has received
    most attention here thusfar.  I want to second Tim's call for a
    Toolkit in particular relation to two other needs: a facile user
    interface and freedom from bugs.  These are necessary so that
    when Alice Anyone feels the need for crypto, she can get software,
    easily used, that prevents foolish misuse, and is both free of
    bugs and weakness to attack.

    At the state of the art, we cannot guarantee these any more than
    we can assert the future security of our algorithms.  But our best
    approach is to get working tools into the hands of testers and
    critical users to begin the process of debugging and revision.
    I would suggest that cypherpunks both write and test code.

    I recommend two books to stimulate thought on debugging and interface
    design, both of which I enjoyed reading.  "Digital Woes: Why we
    should not depend on software" by Lauren Ruth Weiner is a new,
    (First printing - Sept.93) work about bugs.  In 209 pages, backed
    by 365 citations to the literature (often comp.risks), it offers a
    view of the range of software failures that have occurred.  
    Perhaps we can attend to history and not need to repeat it.

    Donald Norman's "Design of veryday Things" is an outstanding work
    on interface design.  An excerpt that I read in Dr. Dobbs one 
    morning made me rush to a bookshop and buy it before noon!
    	HOW TO DO THINGS WRONG
    	If you set out to make something difficult to use, you could
    	probably do no better than to copy the designers of modern
    	computer systems....:
    	* Make things invisible.  Widen the Gulf of Execution: 
    	give no hints to the operations expected.  Establish a Gulf
    	of Evaluation: give no feedback, no visible results of the
        actions just taken.  Exploit the tyranny of the blank screen.
    	...
    	* Be inconsistent: change the rules.  Let something be done
    	one way in one mode and another way in another mode. This is
    	especially effective where it is necessary to go back and forth
    	between these modes.
    	...
    	* Make operations dangerous.  Allow a single erroneous action
    	to destroy invaluable work.  Make it easy to do disastrous
    	things.  But put warnings in the manual; then when people
    	complain, you can ask, "But didn't you read the manual?"