I'll just leave this here in case it's useful to someone else: If your web server host allows only SFTP (a good idea for security), you'll find that Composer doesn't support SFTP. For reasons of tool familiarity and process, I did not want to impose a change of HTML editor on the maintainer of a certain web site, so I came up with the following workaround for users who prefer to use the Composer HTML editor and didn't want to learn a new one:

1. Start a local FTP server on the user's machine. In this case it was Mac OS X 10.5; setting up an FTP server was as simple as turning on File Sharing in the Sharing section of System Preferences, checking the firewall settings to make sure the FTP server was visible only to the local machine, and editing /etc/ftpchroot to contain a single asterisk character for security.
2. Create a directory in the user's home directory called ~/proxy_for_website/
3. Inside that directory, mimic the directory structure that exists already at the web hosting company, e.g., ~/public_html and ~/secure_html and all subdirectories that might exist below them.
4. Inside Sea Monkey Composer, change the Publish As... settings as follows:
5. • Publishing address: ftp//name_of_user's_machine.local/proxy_for_website/public_html/
   • User name: the user's username on the local machine.
   • Password: the user's password on the local machine.
6. Now set up an SSH public key pair on the user's local machine and on the web hosting company's server in the usual way so that SSH can be done without a password (hint: use ssh-agent to do it securely). This will ensure that rsync can run automatically.
7. Set up a cron job on the user's machine to run the following script once every minute:

#!/bin/sh

#
# This script watches for any change in the $target directory, and if it
# sees a change, copies whatever changed to the user's public_html directory
# at Hurricane Electric. Run this script once a minute from crontab.

start_time=`date +%s`

old_detectfile=/Users/username/detect_mozilla_upload_content.new

new_detectfile=/Users/username/detect_mozilla_upload_content.old

reportfile=/Users/username/detect_mozilla_upload_report

target=/Users/username/proxy_for_website/public_html/

rm -f $reportfile; touch $reportfile

cd $target
find . -type f -ls > $new_detectfile
diff -q $new_detectfile $old_detectfile

RC=$?
if [ $RC -eq 0 ]; then
echo "nothing to do at `date`" >> $reportfile
else
echo "\nchange in the proxy directory detected (diff rc was $RC) ; running rsync now\n" \
>> $reportfile

rsync -avz . username@he.net:public_html >> $reportfile
RC=$?
echo "\nRC from rsync was $RC" >> $reportfile

mv $new_detectfile $old_detectfile

end_time=`date +%s`
elapsed_time=$(($end_time - $start_time))

echo "\nElapsed time $elapsed_time seconds." >> $reportfile
fi

As a bonus, your user will be pleased to discover that publishing in Composer is almost instaneous now.

Purple House Press, sorry.

Yes! Those books have been reissued, by the way, from Purple Press. They are just as good as you remember.

It was "Threshold" by David R. Palmer.

/. makes no sense as a path. It's been bugging me for fifteen years. Fix it.

The methodology is explained in the paper "The science of guessing: analyzing an anonymized corpus of 70 million passwords" available at http://www.cl.cam.ac.uk/~jcb82/doc/B12-IEEESP-analyzing_70M_anonymized_passwords.pdf Plain text passwords were captured at login time in coöperation with Yahoo! under ethics and legal-approved rules. The experimental design contains technical measures to ensure that user IDs were not associated with passwords and further measures to protect against passwords that might be used in more than one place.

"Don't pick up things off the sidewalk and eat them."