RISKS@KL.SRI.COM (RISKS FORUM, Peter G. Neumann -- Coordinator) (07/20/88)
RISKS-LIST: RISKS-FORUM Digest Wednesday 20 July 1988 Volume 7 : Issue 25
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Possible reason for unexpected Audi 100 acceleration (Lars Lindwall)
Bell blames computer error as $4 calls are billed for $400 (David Sherman)
Programming BART (Bay Area Rapid Transit) (Eugene Miya)
Re: The IRS Illinois Experiment (Michael L. McLean, Lars J Poulsen)
Error rates in barcode data (John Colville)
PIN on PNB calling card (Nathan K. Meyers)
Re: Risks of bank ATM cards (George H. Feil)
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome.
CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line
(otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM.
FOR VOL i ISSUE j / ftp kl.sri.com / login anonymous (ANY NONNULL PASSWORD) /
get stripe:<risks>risks-i.j ... (OR TRY cd stripe:<risks> / get risks-i.j ...
Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85),(6,95).
----------------------------------------------------------------------
Date: Tue, 19 Jul 88 18:00 N
From: <L_LINDWA%SELIUC51.BITNET@CUNYVM.CUNY.EDU> (LARS LINDWALL LIDAC)
Subject: Possible reason for unexpected Audi 100 acceleration
The following is what I can recall from a news story in the Swedish
Broadcasting Corporation's "News for Consumers" ("Konsumentekot") today,
Tuesday July 19th, 1988.
A researcher at the Swedish National Defense Research Institute (FOA) claims
that he has found a possible cause for the well known Audi 100 involuntary
acceleration phenomena. The researcher, Mats Gunnerhed, active in the field of
reliability of technical systems, says that the automatic speed control
probably is to blame for many of the accidents. By manipulating just one of the
connections on the electronic board that is part of the cruise control
function, he has been able to reproduce the unexpected applying of full
throttle. It is not necessary for the cruise control to be activated for the
acceleration to happen. It is enough that the main power switch for the
automatic speed control is in the "on" position.
Gunnerhed says that the construction as described on the drawings seems good
and reliable. A double electronic fault would be required for the involuntary
acceleration. However, when the construction was implemented on a physical
electronic board a mistake was made that makes it possible for one single
electronic fault to cause the unexpected acceleration.
A representative of the cruise control manufacturer, the West German company of
HELLA, says that double security is still present since the human error of not
applying the brakes is also required for an accident to happen (sic!).
Lars Lindwall, University of Linkoping Computer Center, Sweden.
(LLL@SELIUC51.BITNET)
------------------------------
Date: 19 Jul 88 16:21:46 EDT (Tue)
From: lsuc!dave@uunet.UU.NET (David Sherman)
Subject: Bell blames computer error as $4 calls are billed for $400
Toronto Star, July 14, 1988:
OTTAWA (CP) -- Thanks to a computer error, massive long-distance bills have
been charged to people in Ottawa who phoned Toronto between May 26 and June 10.
Customers were billed the maximum 999 minutes -- or 16 hours, 39 minutes -- for
all calls because the computer did not register the signal given when a phone
is hung up, Bell says. As a result, a 10-minute call that should have cost $4
would be billed at a whopping $400.
One business, among 83 customers who have already complained, was charged a
total of more than $13,000. The average overcharge was $2,450, said Bell
spokesman Mary McGregor. Some customers received notices warning that their
phone would be disconnected in three days unless they paid up. More complaints
are expected when subscribers receive their next bill, McGregor says.
------------------------------
Date: Tue, 19 Jul 88 18:25:19 PDT
From: Eugene Miya <eugene@amelia.nas.nasa.gov>
Subject: Programming BART (Bay Area Rapid Transit)
On a recent climbing trip, the subject of RISKs (this newsgroup) was brought up
in discussion with a partner who heads the programming for BART. I passed on
the reference to Perrow's "Normal Accidents," which he had read and really
enjoyed [and I also told him of various discussions on programming railway
systems, note: Bob is English]. Anyway he brought up some interesting points:
the current system is only programmed for a maximum of 45 trains (future
extensions may require complete reprogramming); BART is a real-time system with
3,000 independent inputs; they use a Yourdon Design Methodology for
programming, etc. Oh, yes, he has some interesting stories (like the BART
switching yard is not part of BART control, so this nearly led to several
accidents), so we can get some interesting antecdotes if RISKs wants them.
Anyways, since Bob is heading back to England this fall and the fact that BART
is isolated from any networks (Bob being interested in RISKS), I will agree to
act as intermediary for questions about the real-time programming of BART. I
will next be seeing Bob in about 2 weeks, so I can batch questions together
forward them and an answer if possible. So, if you are interested, and
patient, and don't ask things which are too sensitive (security is a concern),
I will collect questions. Send them to eugene@amelia.nas.nasa.gov for this
purpose (as opposed to my other mail boxes).
eugene miya, NASA Ames
------------------------------
Date: Tue, 19 Jul 88 11:55:37 EST
From: uiucdcs!pur-ee!mlm@uunet.UU.NET (Michael L. McLean)
Subject: Re: The IRS Illinois Experiment
> From: Patrick_A_Townson@unix.SRI.COM
> Subject: The IRS Illinois Experiment
>
> The Internal Revenue Service says it wants to make it faster and easier for
> taxpayers to get their refunds in the future, so it is experimenting with
> a new approach in Illinois during the 1989 tax paying season.
Are you sure about your data? For my 1988 tax return, I went to an H&R block
here in Indiana, gave them my signed tax return and $20 .. They sent the
return in electronically with the paper backup and my refund arrived in the
mail 21 days later. (There was also a 28 day guarantee, if it didn't arrive
H&R block returned the $20 fee -- They must put quite a bit of trust in the
government system for that one)
The paper backup involved the H&R block person copying the vital numbers from
my return onto a different form and sending in my signed return. The
possibilities for errors are enormous. I can just see it now the IRS could get
three different tax returns from me: my original, the paper backup with a
number copied wrong, and the electronic version with a typo.
For an additional cost (don't remember - didn't use this) they had a bank in
Maryland loan you your refund and the loan contract explicitly stated that the
IRS check is payment. That allows you to get your refund within seven days
instead of 28. This also allows the $20+X fee to be automatically deducted
from your refund.
Having used this system once, I would use it for refunds again. However after
reading risks (and the stupid clerk stories in rec.humor) for awhile I would
never authorize the IRS to extract money from my checking account.
I think that a system using PC's would be great, IFF they can make it
secure from hackers. The cost to design it properly would be very
high, and even then I don't think we can get a safe system developed
through the government.
------------------------------
Date: Wed, 20 Jul 88 08:45:59 PDT
From: lars@ACC-SB-UNIX.ARPA (Lars J Poulsen)
Subject: Re: The IRS Illinois Experiment
Patrick Towson's note about the IRS experiment is very interesting.
The projected savings are impressive, but could they be exaggerated ?
The biggest problem is obviously that the email-submitted tax return doesn't
have a signature, and thus it could be hard to prosecute people who file
fraudulent returns in order to obtain a refund to which they are not entitled.
The proposed workaround is to allow filing only through certified tax
preparers, who have something to lose if they are caught assisting with such
fraud.
The note projects that the IRS would save $63.50 for each electronically filed
return, and that the tax preparers would charge $60-$80 on top of their
preparation fee. This seems like a lot of money for what would seem like a
10-minute data entry task. I thought data entry jobs paid about $10-$15/hour;
double that for G&A overheads, and I get $5/return. Network costs may be
another $5, but while these would be a cost to the tax preparers, the IRS would
incur them.
Frankly, the whole idea sounds like a P.R. scheme. "Let's get high tech".
I have no doubt that it saves cost to put data on the machine as early in
the process as possible, but I thought IRS already did this. Where do
these savings come from ?
/ Lars Poulsen
------------------------------
Date: Wed, 20 Jul 88 11:32:57 EST
From: munnari!nswitgould.oz.au!colville@uunet.UU.NET (John Colville)
Subject: Error rates in barcode data
On Monday 18 July, on the ABC's Sydney radio station, 2BL, Margaret Throsby
interviewed a representative of a retail organisation about errors in using
barcode systems. (Sorry, I don't remember his name or organisation).
The rep. quoted experiments in Adelaide which showed that using barcoding
reduced error rates to 5%, compared with earlier experiments in Western
Australia where the error rate when individual items were priced was 15%.
He also defined errors in terms of differences between the price charged and
the price shown on the shelves. Most of the errors he ascribed to failure
of changes to be propagated completely through to the barcode readers
i.e. updates not yet done to tapes, tapes not run through, etc.
There is something rather screwy here. I know that we have inflation in
Australia of, say 7%, and there are *some* specials from week to week.
Even if we assume that the barcode info. is only updated weekly,
it seems to me that 5% error rates are way too high.
[If half the errors are `my' way and half are in the store's favour,
should I buy << 40 items every time to avoid errors? :) ]
John Colville
------------------------------
Date: Mon, 18 Jul 88 17:36:45 pdt
From: Nathan K. Meyers <nathanm%hpcvlx@hplabs.HP.COM>
Subject: PIN on PNB calling card
What exactly is so irresponsible about Pacific Northwest Bell's encoding
charge information into their calling card? It's a credit card -- like
all credit cards, it relies on physical security. If someone steals it,
or your Visa or Mastercard, he has access to your money. Magnetic
stripes on credit cards are pretty common these days -- many of the
charge-type phones that accept your calling card will also accept your
Visa card.
Your calling card does offer a few security advantages over other credit
cards:
1) Nobody can steal your PIN by looking over your shoulder. In other
words, no need to "tear the carbons".
2) You can cut your card to ribbons and throw it away, while still
enjoying its advantages at almost any telephone in the world.
Forget the bulk eraser -- deploy your kitchen shears.
Nathan Meyers, nathanm@hp-pcd.hp.com
------------------------------
Date: Tue, 19 Jul 88 11:08:24 -0400 (EDT)
From: "George H. Feil" <gf08+@andrew.cmu.edu>
Subject: Re: Risks of bank ATM cards (more) (RISKS-6.94)
mordor!lll-crg!lll-winken!ddsw1!karl@rutgers.edu (Karl Denninger) writes:
> o While I was on the phone with Cash Station, Inc. I inquired as to
> the display of balances (this was another "sticking" point with me; they
> were often off by hundreds of dollars). Their reply was that the network
> which interconnects the ATMs "cooks" your balance (!) depending on what
> you do at the terminal. In other words, the balance shown by the terminal
> MAY NOT BE YOUR TRUE BALANCE. When I asked as to why there was no
> indication anywhere that these numbers were "finagled" they indicated that
> the response time of the member bank's computers was insufficient to get a
> real balance.... sounded (and still sounds) fishy to me. Isn't this
> *literally* fraud, as they claim that number on the screen to be your
> BALANCE? (along this line, the machines do not dispense receipts on
> balance inquiries either -- perhaps to prevent you using these as
> "evidence".)
I've been screwed by having bogus balances given by ATM's before.
When I had an account with Mellon Bank (which, in my opinion, is run
by a bunch of weasels for many reasons), the balances which appeared
on my receipts were often as much as 48 hours behind transactions
that already occurred. So, in thinking that I had plenty in my
account, I would make a withdrawal, only to have the bank charge me
$20 for overdrafting my account. They admitted that the balances
weren't always accurrate, and cannot be trusted. Of course, they
don't tell you that when you apply for the card...
Another possiblity is when the bank's computer is down. Sometimes,
the network simply refuses to allow me access to my funds. But at
other times, I was allowed to make a withdrawal, but my account
balance was "unavailable".
It makes me wonder how much banks have made by suckering customers
into believing that they have more funds in their account then they
actually have, and having them unknowingly overdraw on their
accounts?
From now on, I always keep the receipts, and balance the account on my own. My
suggestion: never trust the balance figure that the ATM prints out.
George H. Feil (HAL)
------------------------------
End of RISKS-FORUM Digest 7.25
************************
-------