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…
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]
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
> 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]
<>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!
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)
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 ....
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
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
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
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
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
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.]
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
>... 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