Forum on Risks to the Public in Computers and Related Systems
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Volume 7: Issue 9
Wednesday 22 June 1988
Contents
Risks of ATM manufacturers- Philip E. Agre
- Risks of bank ATMs
- Mary-Anne Wolf
Larry E. Kollar - Yet more on the Blackhawk helicopter Jan Wolitzky)
- Re: root typos
- Dave Curry
nyssa - Notice to the OTA mailing list
- Eric Roberts
- Challenger Payoff?
- Richard Outerbridge
- Info on RISKS (comp.risks)
Risks of ATM manufacturers
"Philip E. Agre" <AGRE@AI.AI.MIT.EDU>
Thu, 9 Jun 88 02:05:54 EDT
In reading Risks over the last couple years, I've noticed that responses to attempts to complain about uncorrected technical problems tend to take certain recurring forms. John Pershing's message about ATMs illustrates a remarkable number of these forms of argument, all of which will be familiar from previous Risks discussions of related topics, such as privacy violations and whistle-blowing at NASA. What has happened? Someone, in this case a customer though in other cases it has often been an employee, complains that something is badly amiss with some system, receives no redress, and finds that their reports are ignored. So they make noise about it. The response? 1. Misplaced accusations of uncooperativeness. `You have to exercise the system so that the bugs will be found and fixed.' The person *has* exercised the system and discovered and reported difficulties with it, but the organization in question ignored the reports and thus (we must presume) neither found nor fixed any bugs. 2. Condescending lectures about how `incredibly complicated' the systems in question are and how hard it is to anticipate all possible problems. Nobody has demanded that all problems be anticipated, only that attempts be made to repair detected problems, especially ones that cause unnecessary loss or injury. 3. Misplaced appeals to the market. `If your bank is not responsive to your bug reports, then find another bank.' The ATM didn't just have a bug, it stole this person's money. And presumably it is stealing other people's money. Why doesn't the knowingly misdesigned software constitute a company policy to defraud its customers? And don't ATMs, as a legal matter, fall under some version of the notion of implied warranties of merchantability? 4. Casting misdesign as an irremediable act of God. `It is quite sensible for an ATM's programming to "lean" in the bank's direction is there is something amiss ... .' Wouldn't the really sensible thing be to make a record, whether on a paper receipt or in a computer file, and preferably both, that something was amiss in this particular transaction? 5. Diagnosing the system is the victim's job. `... the consumer will always go complaining to a bank officer. When was the last time that you got *over*-changed and actually reported it?' It is even more sensible to "lean" in the customer's direction, because the bank will always be motivated to fix problems that cost it money. When was the last time a bank discovered it had over-changed you and actually let you keep the money? 6. This-is-nothing-new. `I don't see any risks in his story that can be attributed specifically to the use of ATMs, as opposed to the more general use of a Bank.' Such a statement requires that we define the problem far too abstractly. The story concerned a particular misdesign. Taking it as an abstract attack on ATMs misses the point. 7. Blaming the victim. `It is impossible to even imagine ... the number of ways that clever consumers can subvert the system. Of course, this is nothing new with ATMs -- financial fraud has been around as long as banks.' A customer gets defrauded, yet somehow the issue has gotten twisted around into customers committing fraud. Note the irony of the last bit: banks have committed financial fraud as long as there have been banks.
Risks of bank ATMs
Mary-Anne Wolf <MWolf@BCO-MULTICS.ARPA>
Thu, 9 Jun 88 11:38 EDT
The ATM itself is not all that you need. Baybanks in (Eastern) Massachusetts has a dial-less telephone next to their ATMs, which reaches an office staffed 24 hours a day. I have only used this phone for information, but I assume that, if anything went wrong, it would be possible to inform someone and check the state of the machine immediately. If the bank decided to wait until business hours to check the machine, they could still have a record of who claimed to be short-changed. These ATMs also have a camera behind glass pointing at the customer, and although I never know when it's running, it seems unlikely that someone would fake a complaint. One pays for this convenience with relatively high minimum balances and relatively low interest, but, as long as I have the money, it's worth it. (When I didn't have the money, I got a better deal at a bank with only 2 branches that didn't offer ATMs at all, and a check-cashing card in a 24-hour supermarket for emergencies.) I suspect that the problem is less the machine than the attitude of the bank. A bank should probably rather risk losing a little money than a lot of customers, and I would boycott banks rather than ATMs if I boycotted at all. Mary-Anne Wolf, MWolf -at BCO-Multics.ARPA, Honeywell Bull, Billerica MA These opinions are my own, and my only connection with any bank is as a customer.
Re: Risks of bank ATM cards
Larry E. Kollar <dcatla!mclek@gatech.edu>
Fri, 10 Jun 88 16:43:31 EDT
>From: John Pershing <PERSHNG@ibm.com>
>
> - I have never gotten a receipt for a failed transaction. Requiring a
> receipt for a failed transaction sounds sort-of bogus to me, as one
> of the (dozens of) failures that can happen is that the receipt
> printer breaks or runs out of paper.
The ATMs around Atlanta always give you a receipt, whether or not your
request went through. Usually they have a code on the front, with a list
of codes and what they mean on the back.
As for the printer breaking or running out of paper, it's not a hard thing
for an ATM to detect the lack of paper flow and put itself out of service.
Whether or not ATMs do that is yet another question.
Earlier, Karl Denninger relates that the bank told him "no receipt, no fix."
ATMs keep an internal printout of account numbers, as an audit trail. It came
in handy for us a couple of years back when my wife deposited $400 in cash,
threw the receipt away, and the ATM crashed that evening and forgot to transmit
the transaction. We didn't know what had happened until checks started
bouncing on us. This safeguard must be on all machines; Georgia isn't much of
a consumer-oriented state to require that kind of special modification.
Larry Kollar ...!gatech!dcatla!mclek
Yet more on the Blackhawk helicopter
<wolit@research.att.com>
Fri, 17 Jun 88 10:15 EDT
Additional details on the incident Dave Horsfall reported in RISKS DIGEST 7.8, from 'Aviation Week & Space Technology,' June 13, p. 31: The most recent tests were conducted near a dense antenna field of nearly 1 sq. mi. that radiates on a broad range of frequencies with a power level potential well above 400 MW, according to Army officials. During the tests, the aircraft experienced uncommanded rudder pedal movements that caused the UH-60 [Blackhawk] to begin turning, stiffness in the rudder pedals and illumination of caution and advisory lights in the cockpit. Specifically, the test UH-60 experienced a simultaneous loss of hydraulic pressure to both tail rotor servos for approximately 5 sec. and a jamming of the tail rotor control pedals. Both malfunctions were attributed to the susceptibility of the hydraulic logic module to the high energy levels. As a result, the service has decided to accelerate the hardening of the module for both production and retrofit as the first priority under the modified ECP [Engineering Change Proposal 384]. Jan Wolitzky, AT&T Bell Labs, Murray Hill, NJ; 201 582-2998; mhuxd!wolit (Affiliation given for identification purposes only)
Re: root typos
Dave Curry <davy@intrepid.ecn.purdue.edu>
Thu, 16 Jun 88 12:49:07 EST
Ken Yap relates his problems with ^P and the Vax console. Fortunately,
^P is not the standard rlogin escape.
Here's a better (worse?) one: the console escape character on the CCI Power
6/32 ("tahoe") is the tilde. And, so is the escape character for Berkeley
mail. You guessed it... log in on the console, send some mail, and do a "~h"
to see the headers.... ooops, the machine just halted.
CCI also cleverly placed the "reboot" switch, an up/down toggle, on the
front of the cabinet, not recessed, and at knee level. Fortunately,
UNIX seems to ignore the switch.
--Dave Curry
P.S. - Don't get me wrong; the tahoe is a really *nice* machine, regardless
of the above demonstrations of poor design judgement.
Another Root typo
<nyssa@terminus.att.com>
Fri, 10 Jun 88 13:59 EDT
This has taken on an almost urban legendary status in our group: Four summers ago, we were doing a beta test at a customer site. Our field support person had to remove some files in a directory, so he had to use the "su" command. This he did, followed by an rm -rf * The problem was that he typed "su -" which moved him to the root directory. Not even a series of messages like "/bin/rm: Cannot remove, file busy" detered him, until the machine was wiped out...
A catch for coughin'
Dave Horsfall <munnari!stcns3.stc.oz.au!dave@uunet.UU.NET>
Sat, 18 Jun 88 15:57:42 est
From "Computing Australia" 13 June 1988: "System slip leads to danger dosage An error in instructions given to a pharmaceutical manufacturer's computer has resulted in the production of two dangerous batches of cough mixture. A spokesman for South Australian Hamilton Laboratories, which makes the Neo-Diophen Elixir, said during preparation of the master batch documents for the computer, a decimal placing was typed incorrectly [another decimal point error?]. Some of the mixture was found to contain 10 times the normal level of a certain chemical, he said. He said about 6,400 bottles of the mixture had left the laboratory, but less than half had reached retail outlets. The Federal Community Services and Health Department issued an instant recall on the batches and last week department inspectors were investigating the mistake." So it's not the cough that carries you off, but the coffin they'll carry you off in... Dave Horsfall (VK2KFU), Alcatel-STC Australia, dave@stcns3.stc.oz dave%stcns3.stc.OZ.AU@uunet.UU.NET, ...munnari!stcns3.stc.OZ.AU!dave
I found this amusing, particularly in light of the fact that the
OTA has been investigating SDI software feasibility. /Eric
Congress of the United States
Office of Technology Assessment
Washington, DC 20510-8025
June 6, 1988
TO OTA'S MAILING LIST:
Thank you for your effort in filling out and returning OTA's
yellow update flyer last March and April. Unfortunately, some
software problems have delayed the recording of the new information.
While we are in the process of diagnosing and solving the software
problems, we will be using the non-updated list for sending out
Report Briefs....
We anticipate having the mailing list up and running as normal
in August.
Cordially,
OTA Congressional and
Public Affairs Office
Challenger Payoff?
Richard Outerbridge <csri.toronto.edu!outer@uunet>
Sun, 12 Jun 88 21:44:18 EDT
Recently I heard a litigation lawyer speak on the connection between insurance premiums and corporate motivation. He claimed that despite the shuttle disaster Morton Thiokol still received a $65 Million dollar "early completion" bonus on the contract that included the Challenger launch. Is this true? 'Twere scandalous 'twere so, but stranger (and sorrier) things have been known true.
Report problems with the web pages to the maintainer