The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 16 Issue 49

Monday 24 October 1994

Contents

o "Computer Related Risks" by Neumann
Rob Slade
o Half a degree is better than none?
Mark Brader
o Re: Barclays Bank Banks Big-Bang Bump-up
Mark Brader
o Re: Not enough bytes bites again
Dave Moore
o The FTC wades in
Don Blumenthal via Joel K. Furr
o That Macintosh Power Switch
Don Norman
o The Risks of Ignorant in Computer Science
Yaron Y. Goland
o More on risky interfaces
Mike Perry
Gary Page
Brad G. Parks
Jean Renard Ward
Kevin Purcell
Kent Borg
Mike Alexander
o Info on RISKS (comp.risks)

"Computer Related Risks" by Neumann

"Rob Slade, Ed. DECrypt & ComNet, VARUG rep" <roberts@mukluk.decus.ca>
Sun, 23 Oct 1994 20:01:52 EST
BKCMRLRS.RVW  940906

"Computer-Related Risks", Neumann, 1994, 0-201-55805-X, U$24.75
neumann@csl.sri.com
%A   Peter G. Neumann
%C   1 Jacob Way, Reading, MA   01867-9984
%D   1994
%G   0-201-55805-X
%I   Addison-Wesley Publishing Company
%O   U$24.75 (22.25 for ACM, order no. 706943)
%P   384
%T   "Computer-Related Risks"
Heather Rignanesi, Marketing, x340, 73171.657@Compuserve.com
Barbara Warren, Marketing barbarw@aw.com
Tiffany Moore, Publicity  tiffanym@aw.com
800-822-6339
617-944-3700
Fax: (617) 944-7273

Every technologist should, at some point in the educational process, be
required to read this book.  (The preceding proviso is, unfortunately, subject
to the risk that said technologist may fail to grasp the book's underlying
lessons.)

Peter G. Neumann is well known to the members of the Association for Computing
Machinery (ACM), but to thousands more he is known as moderator of the RISKS-
FORUM Digest electronic mailing list (or its Usenet mirror, comp.risks).
(RISKS is notable for the quality and interest of its material, and is a
recommended mailing list for all newcomers to the Internet, regardless of their
areas of interest.)  This work is not merely a compilation, but a distillation
of the type of material discussed on RISKS.  The occasional item is not
strictly computer related (an ongoing RISKS discussion itself), but all
demonstrate the variety of ways in which technology may constitute a hazard.

Written primarily in the format of a textbook for an academic environment, the
material is not only readable but fascinating for a non-technical audience.
The end notes, challenge questions and bibliography make it an excellent choice
for any course dealing with security, safety or general systems development
issues.

(We interrupt this review to note that PGN is able to write over two-and-a-half
pages of the Preface before we find the first pun.  By the end of Chapter two,
he is in full flight.  I refer you to "Tempest Puget, or The Sound and the
Ferries" for full multi-model, cliche-referential punning entries.)

As well as system and software engineering students, this book should have a
place on the desk of anyone involved in a technology development project.  It
*can* happen here.

copyright Robert M. Slade, 1994   BKCMRLRS.RVW  940906   604-984-4067
DECUS Canada Communications, Desktop, Education and Security group newsletters
Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733
Author "Robert Slade's Guide to Computer Viruses" (Oct. '94) Springer-Verlag

    [Thanks, Rob!  PGN]


Half a degree is better than none?

Mark Brader <msb@sq.sq.com>
Sun, 4 Sep 1994 00:59:38 -0400
I recently obtained the new 5th edition of The Official Encyclopedia of
Bridge, the major reference book published by the American Contract Bridge
League.  It happens that several different numbers that relate to bridge can
occur in half-integers -- you can be in a 6.5-table duplicate game, hold 3.5
quick tricks, score 1.5 (in the American style) match points, and so on.  Where
I have used the two ASCII characters .5 in this posting, the book naturally
uses the single character 1/2 instead.

Or rather, it tries to.  Somehow, wherever the character 1/2 is supposed to
occur, instead there is a degree sign!

Somehow I doubt that that'd ever have happened without computer typesetting.
An obvious guess is that all drafts for proofing were done with a font
having a different character set or encoding from the one used in final
production.

Mark Brader, SoftQuad Inc., Toronto   msb@sq.com


Re: Barclays Bank Banks Big-Bang Bump-up (Randell, Risks-16.46)

Mark Brader <msb@sq.sq.com>
Thu Oct 20 15:28:01 EDT 1994
> Barclays refuses to disclose the cost of the project, but it is believed to
> have invested fllOm in customer-based systems. ...

FLLOM to you too!  I assume that's 110 million pounds sterling.
Risks of using a scanner to submit to RISKS...

Mark Brader, msb@sq.com  SoftQuad Inc., Toronto

   [Also noted by Amos Shapir <amos@nsof.co.il>, and
   by PGN, who did not get around to fixing it.  Cute.  PGN]


Re: Not enough bytes bites again (Auslander, RISKS-16.48)

Dave Moore <davem@garnet.spawar.navy.mil>
Mon, 24 Oct 1994 10:39:39 -0400 (EDT)
<>NOTICE ADVISORY TO NAVSTAR USERS (NANU) 222-94266

I just wanted to make clear to anyone interested that the described problem is
not a defect in the GPS system, it is a failure by certain receiver
manufactures to properly implement the specifications.

The referenced subsection refers to the handling of "Leap Seconds".
<Note: Leap Seconds are unrelated to leap years.>

GPS maintains time as second count from a base value.  Off the top of my head,
I believe that the base time is midnight Jan 5/6 1980.  GPS maintains a COARSE
time field as a 10 bit week count from this base.  There is also a sub field
that warns of leap seconds in the near future or recent past.  To save bits,
the leap second warning only uses the least significant 8 bits of the 10 bit
week field.  The receiver is supposed to performed a clearly specified
algorithm to account for this 4+ year subrange.  Apparently some receiver
manufactures did not properly implement this.

On a speculative note: The GPS satellite 10-bit week field should roll over
sometime around August 1999.  At that time the base time reference of Jan 1980
becomes August 1999.  I wonder how many receivers will correctly handle that
rollover?  If any of you out there have access to a receiver you can play
with; try initializing it with a date of Oct 1999 and see if it correctly
initializes itself to 20 years (1024 weeks) in the future from current time,
or drops back to current time implying a hard coded base of 1980 that may not
work after August 1999.  Note that this is speculation on my part; I don't
know for sure that this interpretation is correct.

As always; your mileage may vary!


The FTC wades in

Joel K. Furr <jfurr@acpub.duke.edu>
24 Oct 1994 11:39:19 -0400
From: Don.Blumenthal@wpo.ftc.gov

FOR RELEASE:  SEPTEMBER 14, 1994

      FTC TARGETS ADVERTISING ON "INFORMATION SUPERHIGHWAY":
  Credit repair co. urged consumers to falsify data, FTC Charged

     In its first case targeting advertising on the "information
superhighway," the Federal Trade Commission has charged a Sacramento,
California, man with making false claims in the course of promoting his
credit-repair program on an on-line computer service.  The FTC alleged that
Brian Corzine, doing business as Chase Consulting, promoted his $99 program on
America Online.  The program allegedly advises consumers to take illegal steps
in order to repair their credit records, while representing that it is "100%
legal."  At the FTC's request, a federal district court has ordered a
temporary halt to the alleged deceptive promotion, and frozen Corzine's assets
to preserve any funds for consumer redress.

     "As these computer networks continue to grow, we will not tolerate the
use of deceptive practices here any more than we have tolerated them on other
recently-emerged technologies for marketing products and services to
consumers," said FTC Chairman Janet D.  Steiger in announcing the case.

     In its complaint detailing the charges in the case, the FTC alleged that
Corzine (also known as Brian Chase) advertised his credit program on America
Online, instructing consumers to contact Chase Consulting through the computer
service.  Corzine allegedly enticed consumers to do so by using statements
such as:

     -- "FOR JUST $99.00 WE WILL SHOW YOU HOW TO CREATE A BRAND NEW
     CREDIT FILE AT ALL 3 OF THE MAJOR CREDIT BUREAUS...100% LEGAL
     AND 200% GUARANTEED."

     Consumers who contacted Chase Consulting by computer received a
three-page description of the program instructing them to obtain a "taxpayer
identification number" from one of a few specific Internal Revenue Service
regional centers and then to use this number in place of their Social Security
number on credit applications.  The complete "file segregation" program
included a booklet which further instructed consumers to obtain two new
addresses: one for use on their driver's licenses and one for use on credit
applications.  Corzine allegedly represented that the program is legal.  But
consumers who falsify statements on certain loan and credit applications or
falsify their Social Security number would violate one or more federal
criminal statutes, the FTC said.

     The FTC has asked the federal district court to issue a
permanent injunction against Corzine prohibiting him from engaging
in these kinds of practices in the future, and ordering him to pay
consumer redress.

     The FTC vote to file the complaint was 3-0, with Commissioner Dennis A.
Yao not participating.  It was filed under seal in U.S.  District Court for
the Eastern District of California, in Sacramento, on Sept. 12, 1994.  The
seal was lifted late yesterday.

NOTE: The Commission files a complaint when it has "reason to believe" that
the law has been or is being violated, and it appears to the Commission that a
proceeding is in the public interest.  The complaint is not a finding or
ruling that the defendant has actually violated the law.  The case will be
decided by the court.

     Copies of the complaint and free FTC brochures for consumers titled
"Credit Repair Scams," "A New Credit Identity: A New Credit Repair Scam," and
"How to Dispute Credit Report Errors," which offer tips on avoiding these
types of schemes and correcting your own credit record, are available from the
FTC's Public Reference Branch, Room 130, 6th Street and Pennsylvania Avenue,
N.W., Washington, D.C.  20580; 202-326-2222; TTY for the hearing impaired
202-326-2502.
                               # # #

MEDIA CONTACT:      Bonnie Jansen, Office of Public Affairs
                    202-326-2161
                    bonnie.jansen@wpo.ftc.gov

STAFF CONTACT:      Bureau of Consumer Protection
                    David Medine, 202-326-3224
                    david.medine@wpo.ftc.gov

                    Jeffrey S. Markowitz, 202-327-2460
                    jeffery.markowitz@wpo.ftc.gov

(FTC File No. 9423295)
(Civil Action No. CIV-S-94-1446 (DFL))
(chase)


That Macintosh Power Switch

Don Norman <dnorman@apple.com>
Sun, 23 Oct 1994 10:39:00 -0700
Suddenly RISKS has become concerned over the placement of the power switch on
the on a model of the Mac. Sigh. The concern is justified, but the solution
not quite so apparent.

Would RISK readers be reassured or appalled to discover that several months
ago I thrust myself into the battle and now am in charge of solving the
problem? Ah, a simple problem, one I thought would offer some relief from the
more substantive issues I normally grapple with. All I had to do was find a
consistent logical spot to put the power switch, and do it right, once and for
all.

Wrong. Now several months later, after numerous meetings and roughly ten
draft proposals, meeting with roughly 30 people from several divisions of
the company, we are perhaps near a solution. Perhaps, but hardly a week ago
a new problem arose that, as yet, does not have a solution.

Let me tell you, it isn't easy to do a consistent policy on power switches.
The proposal, plus justification is 21 pages. First of all we have an
incredible variety of machines, from those used as high power workstations,
to servers (which need protected power switches), to office, home, and
educational machines. And portables. Some machines are placed on the desk,
often with the monitor on top.  Some are placed on the floor.  Some are
rotated to stand on their side. Some would seem to require clearly marked,
easily accessible switches. Some need switches out of reach.

On top of these problems, we don't even want people to use the power
switch: it invariably leads to damage. We prefer them to use the shutdown
menu which can do a neat, orderly quitting of applications and safe
shutdown. Under normal conditions, it would be best not to have a power
switch at all. But sometimes it is necessary to disconnect power. And I
have even heard it claimed that our software sometimes crashes (really?),
so that a soft, graceful shutdown isn't possible. In this case, some sort
of shutdown switch is required, one that bypasses system software.

Some otherwise simple solutions are ruled out by cost considerations. In
the low-end market, where cost dominates and the profit margins are
negligible, even a very slight extra cost can disrupt product sales, so if
we want a uniform policy for all machines, it has to be one acceptable to
the most cost-conscious product.

Finally, we must satisfy international safety requirements, have a solution
that works across the world with a variety of languages and cultural
expectations, and that can be used by people with a variety of
disabilities. It has to be readily understood by first-time users, people
who may never have used a Mac before, but not annoy our skilled, power
users. Moreover, the problems are tightly coupled with the need to reboot
occasionally, and programmers need a way of getting into the debug state.
And as I said, the solution has to work for both the normal situation and
the case where the system software is no longer responding. The power
switch problem therefore also becomes the problem of providing capabilities
to "reboot," to do an "emergency power down," and to get access to the
"debug state." Not to mention labeling the power key.

You wouldn't believe how much time we spent on the problem of appropriately
labeling the switch. The left-facing triangle on the keyboard switch is
there because it doesn't mean anything. (Honest.)  The earlier symbol
(vertical line inside a circle) was not permitted because the European
standards people wouldn't let us use it  -- that symbol was reserved for
hard power switches. The triangle has no meaning, so it didn't violate any
standards. Mind you, the legal symbols are just as non-meaningful to most
people. Few -- European or American -- are confident about the meaning of
the vertical bar and circle (on and off, respectively), let alone bar
inside of circle (a toggled on/off), or vertical bar inside broken circle
(toggled soft-power),  but the European standards committee is very strict.
There are safety risks associated with thinking a shutdown switch removes
all power from the machine when it doesn't. (Today, many electronic devices
never have all power removed. The "power" button on the television remote
does not do a hard shutdown, nor does the "shut down" menu choice on the
Mac.  After all, if they really shut down all power, the TV remote wouldn't
be able to turn the power back on, nor would the Mac's keyboard turn on the
machine. Your clock radio, for example, is not really off when you turn
"off" the power. If it were off, how would the clock be powered?)

So, what seemed to be a very simple task, one that would remove all the
confusions of our power switch locations, to say nothing of the infamous
problem newly discovered by RISKS readers (but well known within Apple)
where the keyboard can accidentally hit the power switch (nobody in RISKS
commented on that -- you guys are slipping!) turned out to be incredibly
complex. Yes, people turn off the power thinking they are pushing the
diskette eject button. Macs don't have a diskette eject button -- we eject
disks gracefully, under program control -- which is why the designers
failed to note this problem prior to manufacture: it is users of non-Mac
machines that have this problem. This is not justification, but I am
continually amazed by the number of usage combinations that have to be
tested -- it feels infinite -- so no matter how thorough the user testing,
new situations arise after the product is shipped, situations that the
bystander thinks so obvious that the designers must have been stupid not to
have noticed (ah, that famous paper again: hindsight is not equal to
foresight).

(By the way, you can't have a warning message come up when the power switch
is hit for several reasons, the simplest being that if the software has
crashed, you can't guarantee that the message would be displayed or the
response attended to -- you need some way of forcing a shutdown when
everything else has failed.)

(And while I am at it, don't suggest that our job would be simpler if we
simply made software that never crashed. Or that we could use a watchdog
timer to do automatic reboots.Yes, but ...  .)

So what will we come up with?  Can you live without a power switch on the
CPU box, assuming all other cases have been dealt with? Assuming the system
were protected against accidents. What if the switch were only in the rear?
(Remember, we don't want people to use it under normal circumstances.)

Will my committee actually be able to find a common proposal that all the
divisions of the company can accept? Who knows? Will the solution we are
close to adopting solve all problems? Almost definitely not. Will it be an
improvement over the current solution? Absolutely. Could we have done
better? Maybe, but  if we knew how, we would.

Whew: look how long this simple note has become, just to clarify the nature
of the problem. Symptomatic.

(As for Calling Number Identification: once the power switch task is
finished, it will be a relief to turn to something easy.)

Don Norman (severely chastened design critic and practitioner).
User Experience Architect. Apple Computer. Cupertino, CA USA. dnorman@apple.com
....


The Risks of Ignorant in Computer Science

Yaron Y. Goland <ygoland@hollywood.cinenet.net>
22 Oct 1994 11:34:24 -0700
I am a senior at UCLA in Computer Science and Engineering and we have no such
thing as 'human engineering classes', 'interface design classes', or 'software
management' classes. We are taught lots of theory about computer science but
absolutely nothing about how all this theory is supposed to translate into
products that people can use. So the next time you want to smash your computer
into pieces because its interface is a nightmare or the system has just
crashed for the 7,000th time you can feel sure that the next generation of
computer scientists, at least from UCLA, hasn't been taught a single thing
about how to do better.

The risks should be obvious.

Yaron Y. Goland, School of Engineering and Applied Science, University of
California, Los Angeles   ygoland@seas.ucla.edu  73160.327@compuserve.com


Re: Risk of similar interfaces

<Mike_Perry@dge.ceo.dg.com>
Mon, 24 Oct 94 10:18:48 edt
The postings on the problems of similar looking buttons (RISKS-16.47&48)
reminded me of a related RISK of failing to understand user perceptions.

Some years ago, an electronics/avionics/computer/etc company (best they remain
anonymous) manufactured a military C3 system for use in trucks.  Part of the
equipment consisted of a small minicomputer which was installed under a
desktop in the back of the truck.  The mini had a button on the front labelled
"BOOT".  The squaddies operating the gear took this to mean the method of
operating the button, rather than its function.  Not surprisingly, the button
and switch had a very short life.  Education consistently failed to solve the
problem, and in the end the switch had to be redesigned with a large, heavy
duty, heavily sprung steel button that then could ONLY be operated by a kick.

Mike Perry   mike_perry@dge.ceo.dg.com


Another problem with seemingly similar interfaces

ICTT) Mon, 24 Oct 94 10:32:44 EST
The recent article about the location of power buttons reminded me of an
incident that occurred a few years ago.

The bank that I used switched over from one version of ATM software to
another.  In the old version you had to enter your PIN, then press a
special key to get the ATM to accept it.

Somebody decided that this was a waste of effort, since all the PINs were
the same length, so the machine could tell when you were done.  Therefore,
they removed the extra keystroke.

This might have been fine except for what they did with that key.  It became
a selection of what you wanted to do.  Unfortunately, it became the Fast
Withdrawal button, which takes a fixed amount of money out of checking,
without any more chances to stop it.

Just imagine what this could do for people who were trying to put money
into checking because the balance was too low.

Anyway, there were huge signs up around the ATM for months warning up this.
Even so, I made the mistake myself once.

This shows the RISKs of even good-hearted changes to the user interface.

Gary Page  International Centers for Telecommunications Technology
page@acd4.acd.com


RISKy interfaces

Brad G. Parks <bparks@intcorp.com>
Mon, 24 Oct 94 15:29 CDT
The power switch isn't the only button that can be dangerous to have near
other familiar buttons.  As a help-desk assistant at a small Minnesota
college, [I noted] the most common mistake students and faculty would make on
the Heath terminals wasn't the power switch.  (The terminal could just be
switched back on to pick up where they left off) Instead, people were often
pressing "Hold Screen" -- a pretty handy button for lengthy and scrolling
messages -- which was right next to the shift key.

Before notifying the lab assistants that their terminal "just froze up" they
would try everything in their power to get the terminal to respond.  This
included pressing every function key and command sequence -- often with
disastrous results and changes (which never appeared until "Hold Screen" was
toggled again) to their document in their favorite terminal based word
processor.

Many documents were lost and professors embarrassed by mistakenly pressing
that one key.

Brad G. Parks (bparks@intcorp.com)   [Software Engineer, O-Programmer]
Introl Corporation (612)-631-7810  2675 Patton Rd. St.Paul, MN  55113


Re: Risk of seeming similar interfaces (Elkins, RISKS-16.47)

Jean Renard Ward <jrward@world.std.com>
Sat, 22 Oct 1994 19:46:16 -0400
This discussion reminds me of a bit of folk-wisdom in the Software community
in this area: All PC's made to run Microsoft's Windows and DOS products seem
to be designed mechanical switches to open the floppy drive, and with the
reset (or at least the power or "hard reset") button mounted __conveniently__
on the __front__ of the computer for easy access.  Most machines made now to
run Unix (Sun, HP, other workstations) and Apple's MAC operating system do
__not__ have mechanical switches on the floppy drive, and do __not__ usually
have the "emergency" reset switch on the front.

The folk wisdom is that you __need__ these emergency switches located for easy
access when the software you are running is unreliable and crashes often.

Jean Renard Ward    Boston, MA USA  jrward@world.std.com


Re: Risk of seeming similar interfaces (Elkins, RISKS-16.47)

Kevin Purcell <xenolith@halcyon.com>
Fri, 21 Oct 1994 19:39:51 -0700
The misplacement of the front-panel-mounted push-button power switch on a
Power Mac 6100 or Centris/Quadra 610 shows the interesting effects of the
interactions of manufacturing costs and human interface design.

It seems as if there were two goals:

1. Putting a power switch on the back panel of the computer hides the switch
and makes the user rely on memory to operate the switch.  So, moving it to a
place where it is visible is a good idea.

2. Power supplies with a relay triggered by a momentary action switch (or a
signal on the Apple Desktop Bus) are more expensive than power supplies
that have a simple on/off latching switch.

Finally, the unwritten assumption that all Macintoshes have a powered eject
of the floppy disk that automatically ejects the disk from the disk drive
when you ask for the disk to be removed. No Mac user every pushes a button
to eject their disk. This includes all the Macintosh hardware designers.

The goals (1) and (2) are combined to place a on/off latching switch on the
front panel, despite the fact that the Machintosh system software has always
used a shutdown command selected from a menu to do an orderly close down.

The original design problem was solved with the introduction of the Mac II.
A switch on the keyboard turns the Mac on, but the Mac can only be shut
down by the menu command.

A combination of these two concepts plus a blindness (from good design) leads
to the poor design where a user can destroy all of his work in a second or so.
In the best case, I've seen a user press the button, realize that they've just
made a big mistake, and start to save their documents while keeping their
finger on the button.

Kevin Purcell, Seattle dBug Mac Developers SIG Organiser  kevinpu@atm.com
xenolith@halcyon.com  206/649-6489  N7WIM + G8UDP

 [Several garbles edited around by PGN.]


Re: Risk of seeming similar interfaces (Elkins, RISKS-16.47)

Kent Borg <kentborg@borg.org>
Sat, 22 Oct 1994 01:40:21 -0400
Would you like to understand *why* Apple put an eject-looking power switch on
some of their machines?

Stupidity is too easy an answer.  A more subtle explanation revolves around
the fact that Macs don't *have* disk eject switches.  They eject floppies by
software.  How can a power switch look like something that doesn't exist?  It
can't.  This button is not much of a risk...to *Mac* users.  It is the
IBM-compatible folks who will be screaming bloody-murder.

Moral: Anticipate users from beyond your own little world.  (Particularly
if your marketing folks are trying to sell to them.)

-kb, the Kent who uses Macs.

Kent Borg  kentborg@borg.org  kentborg@aol.com   +1 (617) 776-6899


Re: Risk of seeming similar interfaces (Elkins, RISKS-16.47)

"Mike Alexander" <Mike.Alexander@umich.edu>
Sat, 22 Oct 94 23:21:48 -0300
>...  Will Apple never learn?  ...

I find this thread a bit odd. I've used many Macs, including both the PowerMac
7100 and 8100, and none of them newer than a Mac SE even has an accessible
power switch.  Assuming the original poster is talking about the reset button,
on all of the machines I've used, it is a small button placed about as far
away from the floppy disk drive as is reasonable.  For example on the 8100 I'm
using to send this, it is at the bottom right corner while the floppy and CD
Rom drives are at the top.  It would be very hard to confuse the reset button
with an eject button.  Perhaps the 6100 has this problem, I haven't used one
of them, but if so it's the exception not the rule.

Mike Alexander, University of Michigan, ITD - Research Systems
mta@umich.edu  MAlexander@aol.com   AppleLink: UMICH

Please report problems with the web pages to the maintainer

Top