The RISKS Digest
Volume 9 Issue 38

Tuesday, 31st October 1989

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


Passwords in the Electronic Home
Gary McClelland
A new excuse
Ernest H. Robl
Hot computers and temperature-sensitive programs
Donald Arseneau
Re: Hi-tech loses in cars
Paul Fuqua
Article on computer crime laws
Peter Ladkin
Work processes which are done faster by hand than by machine
Alexis Rosen
Info on RISKS (comp.risks)

Passwords in the Electronic Home

"Gary McClelland" <>
31 Oct 89 11:55:00 MDT
As various electronic services are brought by phone lines or cables directly to
the home, there will be an increasing need for folks to deal with passwords.
And concomitantly there will be ever more lists of passwords for the nefarious
to try to crack.  RISKS readers may be interested in the following stories
about passwords for two electronic services that recently arrived over the
wires at my house.  From the aspect of security, one story is good and the
other bad.

1.  Voice Mail.  The local Bell company is offering electronic voice mail from
the central switch to residential customers.  Many advantages over an answering
machine.  Not only are both capacity and reliability better than for tape
machine but there are also some nice features that an answering machine could
not have such as answer when busy and a differential ring that lets the caller
know he or she is being switched to voice mail with enough warning that he or
she can hang up to avoid toll charges.  The good story:  on first use the
system requires you to enter a password (min 4 digits, max 8 digits) of your
own choosing.  In contrast, my old answering machine had a 1 digit security
[sic] code.  The password is also easily changed.  I wish my multiple ATM cards
would let me choose my own passwords so that maybe I could remember some of

2.  PRODIGY.  IBM and Sears have teamed to offer a modem-accessible information
and shopping service.  I think we are a test market but maybe lots of you have
this available.  Slick, but slow, graphics, available in either IBM-PC or Mac
versions, offer information on sports, weather, etc. and, depending on locale,
home banking, grocery shopping, and catalog shopping from places ranging from
Sears and Penneys to REI.  One particulary nice feature is access to American
Airlines' Sabre reservations system through a front-end that although is
sometimes tedious is much easier to use than a terminal in a travel agency.
This week I received a promotional letter from AA proffering goodies if I
booked my own flights and paid for them with a credit card through Sabre.
And just in case I had forgotten my password (which they told me never to write
down) they had *printed* it at the top of the promotional letter!  That clearly
means they don't encrypt the passwords they collected from all of us (oh, they
also have our credit card numbers and frequent flyer numbers for faster ticket
ordering).  I wonder how many AA people have access to the password list?
Certainly everyone in the mail room!  But if someone uses my password and
credit card number to order tickets, will I at least get credited for the
frequent flyer miles for the flights they steal?

Gary McClelland, Univ of Colorado             BITNET: mcclella@colorado

A new excuse

Ernest H. Robl <>
Tue, 31 Oct 89 14:50:34 EST
From a conversation overheard a few days ago at the Duke University student
center — yes, this is real; I'm not clever enough to make up something like
this — a new version of the "my dog ate the homework" excuse for not getting a
project done:

     "I told the professor that with the medication I was taking
     it wasn't advisable for me to drive a car, operate heavy
     machinery, OR FORMAT FLOPPY DISKS."

My opinions are my own and probably not IBM-compatible.--ehr
Ernest H. Robl  (ehr@ecsvax)  (919) 684-6269 w; (919) 286-3845 h
Systems Specialist (Tandem System Manager), Library Systems,
027 Perkins Library, Duke University, Durham, NC  27706  U.S.A.

Hot computers and temperature-sensitive programs

Tue, 31 Oct 89 05:51:34 PST
In risks 9.37 Sukumar Rathnam writes

     The last thing you expect is a temperature sensitive
     behavior for programs.

Actually, I've seen it many times and it is now one of the first things I
expect.  And it's easy to test--just turn down the thermostat.
                             Donald Arseneau

Re: Hi-tech loses in cars (Alayne McGregor, RISKS-9.37)

Paul Fuqua <>
Tue, 31 Oct 89 14:29:23 CST

                     Etak manufactures a device for
    keeping track of car movements: a map is displayed on a video screen and
    updated frequently as the car moves, showing the driver where he is and
    giving him the ability to get information about approaching features.

Nicholas Negroponte of the MIT Media Lab used this very application as an
example of the need for speech interfaces to computers.  In his opinion, it's a
terrible idea to have a separate map screen that requires the driver to take
his eyes off the road.  It's much better for the map to talk to him: "Turn left
at Elm Street, 1/4 mile ahead."  Even a heads-up display isn't good enough --
don't overload one channel of communication, use two channels that don't

Paul Fuqua, Texas Instruments Computer Science Center                       {smu,texsun,,rice}!ti-csl!pf

Article on computer crime laws

Peter Ladkin <ladkin@icsib.Berkeley.EDU>
Mon, 30 Oct 89 13:15:49 PST
This week's Economist (28 oct - 3 nov issue) has a leader article on computer
crime (p18), saying that the rush to define new laws on computer crime is
leading to inappropriate suggestions for punishment They say the `real menaces'
are not mysterious or new, but `old-fashioned trespass, vandalism and theft',
and that laws against the former two are hard to apply because ` the "space"
and "property" inside a computer are intangible'. They point out two nonsenses
that have been created by the proposal of Britain's Law Commission, note that
extra-territoriality is a special problem posed by computer crime, and suggest
(platitudinously) that the basic issue of how to protect (rather than how to
punish) needs to be addressed further. In the usual Economist style, it is
well-written and coherent, apart from the conclusion, which is hardly that.

I don't have a scanner, and am unwilling to type it all in. Copies should
hit the bookstores wednesday.

Work processes which are done faster by hand than by machine

Alexis Rosen <alexis@panix.UUCP>
Mon, 30 Oct 89 04:03:27 EST
I'm a newcomer to risks (not the net) but I've followed the discussion of
slow computer vs. fast manual systems.  This is a subject which I've some
familiarity with, and right now I'm just finishing the installation of a
very high-volume POS (point of sale) system implemented on (can you believe
it?) a network of Macintoshes, with receipt printers, cash drawers, and
bar-code scanners.

I have done other systems before which demanded speed, but this job was the
most interesting and difficult I have faced.  From it I have learned a
number of things about the speed that can be achieved with computer systems
in the face of real-world problems.

Problem #1: Careless and unintelligent employees.
Many employees, especially in the kinds of positions that wind up being
automated (cashiers, tellers, etc.) are somewhat less than brilliant. If they
were smarter they'd be rocket scientists, right? :-)  There are many who are
not dumb, and they can be worse, because boredom can make them incredibly

Solution: Management has to be involved in maintaining a decent workplace,
but there are still many things you can do to keep new technology from adding
to the trouble (which would exist no matter what).  I followed the "spirit"
of the Mac interface, which really just means being aware of human factors-
I could not use a mouse *at all*, so goodbye menus and icons. In general,
_everything_ has to be 100% bulletproofed and idiotproofed. These are not the
same thing at all- one protects against illegal values completely, while the
other warns against (but usually doesn't forbid) stupid values.

Example: After a couple of days, employees become aware of the general flow
of events in the program, so they stopped looking at the messages for them
on the screen- in fact they often didn't look at all. They were often unaware
of conditions that required immediate action (bad price entered, for example).
One solution to this particular problem was to create three distinct sounds
that notified users of acknowledgement, notification, and error conditions.

Problem #2: Forgotten Features (and other training issues)
If the system can do so much, how come it's used for so little? Because nobody
remembers how to do this, that, and the other thing. So they all do _this_
instead of _that_ and simply keep paper notes, or figure out some other way
to do less work and screw up the system. Don't fight it, because you'll lose.

Solution: Make sure everything is accessible. Write software that requires
a minimum of training. You want specifics? Start with the Apple Human Interface
Guidelines, and then there's _lots_ of other literature. But to begin with,
don't hide features, don't use cryptic codes when simple english will do, and
don't expect your users to know what they're doing- literally. Either tell
them where they are at all times (unobtrusively, of course) or failing that,
allow them to back out gracefully.   *** BE CONSISTENT ***  and don't expect
users to be the same.

Example: My POS system replaces standard cash registers. It does much much more
and yet takes one-quarter the time to learn. And the features aren't forgotten.
One Mac-ish thing it does is use title bars on all of the windows which aren't
instant-response windows (modal dialogs). The title bars say who is logged in
and what they're doing at all times.

Problem #3: Slow and/or increased data entry
Many computer systems require the tracking of much more information than the
old manual systems.  This can create the illusion of lethargic system speed
even if the hardware is quite fast. Users can be frustrated by the extra
load, which may well feel like makework to them.  The speed of entry itself
may be slow if data is validated on-the-fly as it's entered.

Solution: First, tune the software. You can acheive remarkable things by
using (or, unhappily more often, faking) multi-threading — do the validation,
but _don't_ stop data entry while you're validating. Overlap various hard
delays- print while you're writing to disk, or calculate while verifying a
credit number with a remote machine.
   After all this helps, but isn't good enough, start buying hardware. This
may well be the best part of the system to invest in. Special data-entry
hardware can make a _huge_ difference.

Example: After tuning the POS software, there was still an inevitable slowdown
since the cashiers were entering price and item information instead of just
the price (as on the old registers). This was costing up to fifteen seconds
_per item_, which was completely intolerable. The solution was to buy bar-code
scanners, which could enter both item # and price (both of which are typically
on the item to begin with). This dramatically improves the performance of the
item-entry process.

Problem #4: Lazy programming.
Yes, I am as lazy as the next guy. Often, I'd like the real world to fit a
neat conceptual model I have developed for it. When a case comes up that I
can't handle, I'd rather contort it to fit my code rather than the other way
around. Sometimes this is feasible, and once in a while, it can lead to
marked improvements- but if so, it just identifies an improvement that should
have been realized earlier in the design process. Most of the time, shoehorning
real procedures into flowcharts is a recipe for disaster.

Solution: In that case, recode.  It's as simple and as painful as that.
Sometimes you'll wind up with pages and pages of code to deal with a handful
of exceptions that won't come up but once a year. Tough luck- that's what
being a good programmer is all about.

Example: I designed the POS system so that every item sold would already be
in the database. I went to great lengths to insure this, since it would make
life much easier for both myself and all of the users.  Unfortunately this
can't always work- at times items may be checked in with faulty item codes,
for example.  Modifying the system to deal with unexpected item codes was
one of the most annoying and inelegant things I have ever had to do, but now
it works, and people no longer complain about having to work around a system
which is supposed to make their work easier, not harder.

There is more, but I think that this is more than enough for my first risks
posting.  The point of this is that the system I built is not only more
capable and useful than the old, but is considerably more efficient up front,
as well.  I think that this achievement could easily be duplicated elsewheres
if programmers were more aware of the real-life processes they are trying to
model, and the real-life problems their systems will have to deal with.

Alexis Rosen, President, Arete Corp.  (Hat #1)
Sysadmin/Owner, PANIX public access Unix  (Hat #2)
cmcl2!panix!alexis  -or-  alexis@panix.uucp

Please report problems with the web pages to the maintainer