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…
On July 23, 1992, New York City Mayor Dinkins announced in a press conference
that the $60,000,000 contract to replace the city's mechanical voting machines
with electronic voting systems (EVM) would be awarded to Sequoia Pacific,
pending the outcome of public hearings.
The city's press release included the following statement:
"In January 1989, SRI determined that Sequoia Pacific was best
positioned and most willing to modify its system to meet the
needs of New York City and New York State standards."
In actuality, SRI's Final Report (Evaluation of Offerors for the Procurement
of an Electronic Voting System, December 23, 1988) contained the following
first sentences under FINDINGS:
"No offeror's system completely meets the RFP specifications.
On the basis of our analysis and the testing of the EVMs,
SRI concludes that no offeror currently has either an EVM
or central system acceptable for the city."
They went on to say:
"No offeror scored higher than 63% of the total possible RFP
and evaluation criteria points."
And:
"SRI does not believe any of the four offerors has fully met
the requirements of the RFP, based on their proposed EVMs,
their central systems, and/or management and financial
considerations. Each offeror would have to make substantial,
significant modifications and additions — in both technical
and management areas — for its approach to be considered
acceptable for the City."
SRI went on to recommend Sequoia on the basis that of the four offerors,
they had the greatest "probability of ... successfully implementing an
electronic voting system for New York City."
Does the record indicate that Sequoia has or can successfully implement
a system for New York City? You decide. Here is some information from
public documents:
Monroe County, Indiana vs. Sequoia Pacific:
"In December, 1988, Monroe County, Indiana, filed a lawsuit
against A. E. Boyce and SP, alleging that the defendants
breached a contract between the County and Boyce whereby
Sequoia was to have manufactured and Boyce was to have
delivered to the County 120 automatic voting machines.
Only 40 of the machines were delivered and Sequoia
subsequently ceased production of the model which was
the subject of the contract." "In December, 1990, the
case was settled by the parties. The contract in question
was terminated..."
On July 11, 1990 the Sequoia Pacific Electronic Voting System was denied
certification in the state of Pennsylvania on the following grounds:
"(1) The system does not conform to Pennsylvania statutory
requirements for overriding straight-party votes in individual
offices; (2) the system can be placed inadvertently in a mode
in which the voter is unable to vote for certain candidates,
which is volative of statute; and (3) the system reports straight-
party votes in a bizarre and inconsistent manner."
The NY City Board of Elections stated in a letter on January 3, 1991 that:
"The vendor has admitted to us that release 2.04 of their software
used in the Pennsylvania certification process had just been
modified and that it was a mistake to have used it even in a
certification demonstration."
In what appears to be the final updated evaluation by SRI (June 19, 1991)
of the Sequoia Pacific EVM and its Programmable Memory Device (PMD) which
contains the vote tally, under the heading of Reliability, the testing
status report from Sequoia Pacific stated:
"SP doesn't know how to show that EVM/PMD meets requirement --
this depends on poll workers' competence."
If the above concerns you, here's what you can do:
1. Attend and comment at the public hearings in New York City. It is
critical that individuals have their opinions on this matter stated
for the record, BEFORE the contracts are presented for signing.
New York City residents as well as ALL other interested parties
are permitted to attend.
The meetings are:
August 20, 42nd & Broadway, 6th Floor, 6PM
September 10, City Hall, 10AM (tentative)
2. Request documents from the city under the Freedom of Information Act.
Contact Lorraine Jones at 212/566-3307 in the Department of General
Services. You may wish to request all or some of the following:
A. SRI Final Report, Volume I, December 23, 1988,
Evaluation of Offerors for the Procurement of an
Electronic Voting System.
B. SRI Updated Evaluation of the Sequoia Pacific EVM,
June 19, 1991.
C. Technical Specifications including -
System Requirements Documents
System Design Documents
System Quality Documents
System Verification Plan
System Test Plan
Results of Entire System Test
D. A list of other publications relevant to this matter.
3. Write letters of concern and comment to:
Daniel DeFrancesco
Executive Director
Board of Elections
City of New York
General Office, 32 Broadway
New York, NY 10004
cc separate copy to
Stephanie Dawson
Director, NYC Elections Project
at the address above
Kenneth Knuckles
Commissioner
Department of General Services
Municipal Building, 17th Floor
New York, NY 10007
cc all correspondence to
Election Watch
P.O. Box 1166
Philadelphia, PA 19105
4. If you are a member of ACM, IEEE or other professional, computing or
engineering organizations, encourage your officers and club members
to become involved and informed on this issue.
5. Forward this posting to everyone you believe would be interested in
commenting on this matter.
Rebecca Mercuri mercuri@gradient.cis.upenn.edu
Is there a record for the greatest number of people affected by one computer bug? [This is most likely not it. But it also depends on how you define "affected"... PGN] BANK WARNS CREDIT CARD CUSTOMERS [Cambridge Evening News, 11 Aug 1992] Millions of credit card customers are being contacted to be told their statements might be wrong. NatWest [the National Westminster Bank] is to tell its five million cardholders about the possibility of errors caused by a computer problem - and millions of cardholders with other banks who also have their accounts processed through the same system could be affected. But no-one will lose money as a result of the errors, said a NatWest spokesman. [No-one? Not even the banks? You bet, not the banks...] The mistakes have come about because of a "blip" in the computer system run by First Data Resources. Cards affected include Visa, Mastercard and Access supplied by NatWest, Midland and Lloyds. `We will be correcting it all ourselves. There will be no need for the customer to contact us', said a bank spokesman. [This item was also reported on ITN's TV newscast, where they interviewed a customer whose statement had spuriously acquired a debit for over 4,000 pounds. The credit card bill had automatically been paid from his regular bank account by Direct Debit, thereby making the bank acount overdrawn and attracting heavy interest charges.] University Computing Service, Computer Laboratory, Pembroke St, Cambridge CB2 3QG, England P.Hazel@ucs.cam.ac.uk JANET: P.Hazel@uk.ac.cam.ucs +44 223 334714
[... Jonathan sent in a bunch of further stuff
on this topic, excised for brevity. PGN]
Last night's ITN 10 o'clock news was rather more sensationalist, showing a
short clip of someone on the phone complaining about an unexplained debit of
over 4000 pounds sterling (c $7,500) entry on his account. Surely this must
have been a set-up!
Jonathan Bowen, Oxford University, a Midland VISA card owner.
[In addition, lake@rcwcl1.dnet.bp.com sent in a copy of a U.S. State
Department advisory along similar lines. PGN]
The following is the latest in a series of articles that I have seen in various papers over the last few months about a growing campaign against the practice that UK Banks have of assuming that all cash card fraud is due to stolen or misused cards and pin numbers. (This continues despite the case of the proven cash card fraud carried out by an engineer working for the Clydesdale Bank, if I remember correctly, who eavesdropped electronically on cash dispensing machines.) As I understand it, class actions are comparatively rare and difficult in the UK, so the story is locally interesting just for that reason. However I have not before seen any mention of the way that the barrister leading the action has arranged for computer database and communications technology to be used to gather evidence to counteract the banks' claims - hence this posting to RISKs. Brian Randell - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Banks face legal challenge over cash card fraud By Susan Watts, Technology Correspondent, The Independent, 12 Aug 1992 People convinced they have lost money through cash dispenser fraud could have a novel computer system to thank if they succeed in legal action against their banks due to start tomorrow. Alistair Kelman, a barrister acting for aggrieved customers in a case against seven high street banks and building societies is using computer software to spot patterns in the way unauthorised transactions take place. Mr Kelman has built up a computer database holding information on more than 400 cases. His "relational" database allows him to cross-correlate the place, date and time of mystery cash withdrawals. He hopes to match cases with similar characteristics in a way that he says the banks have so far failed to do. The database will let him analyse "the spider's web" of automatic teller machines across Britain, he said. "I don't think the banks are capable of doing what we are doing. They would only have the pattern of their own branch or their own banking network." Rebecca Evans, a barrister working for the Consumers' Association, said she had already noticed that victims often lived in the same area. Banks have also claimed phantom withdrawals occur near the victims' local cash machine, implying that their personal identification number has been passed on or stolen. She said the database should help to support or dispel such theories. Mr Kelman believes the case is unusual in that it enlisted help from thousands of interested observers via a computer "conference" on the Compulink Information Exchange. This type of electronic message service lets people add their ideas to computer-based "conversations" via telephone data links. Mr Kelman said the case had attracted about 5,000 contributors including policemen, people offering advice on how to make phantom cash withdrawals and others who had had first-hand experience of cashcard theft. One story added to the computer bulletin board recently was from a man claiming his high street bank account was debited from Scotland while he was sitting an exam in Chester with the card on his desk as proof of identification. The bank involved paid up almost immediately, despite the banks' persistent claim that their machines are infallible. Mr Kelman said that linking the cases via his database has enabled him to bring a "group action" against the financial institutions. Denis Whalley, associate solicitor at Keith J Park in Merseyside who is preparing the cases, said Mr Kelman's approach had helped him secure legal aid for many of the plaintiffs even though most were claiming less than (pounds)1,000, which would normally be too small a claim to qualify. He intends to issue writs on 10 cases tomorrow, then add to these over the following months to work towards a full trial next summer. Mr Whalley said the banks had become more willing to pay up as his court case approached. But a spokesman for the Association of Payment Clearing Services the banks' cheque clearing system insisted yesterday that the banks were confident in the security of their computer systems and fully prepared to face the court action. Dept. of Computing Science, The University, Newcastle upon Tyne, NE1 7RU, UK Brian.Randell@newcastle.ac.uk PHONE = +44 91 222 7923 FAX = +44 91 222 8232
Source: St Pete Times, 8/12/92, pg E1, Robert Trigaux By the close of business Tuesday, Barnett Banks Inc had learned what it is like to be an 800-pound gorilla wearing a blindfold. Florida's largest banking company opened its 550 branches statewide Tuesday only to find its computers were taking the day off...branches could not open a new account or check balances in any customer's account. Most branches set dollar limits on cashing checks and worked to minimize the confusion. But Barnett customers with big transactions to make and who did not pass a 'Do I know you' test of branch managers were out of luck for the day. ... Though computer experts spent most of Tuesday in search of the 'bug' that plagued Barnett's systems, they were not able to identify it and fix it before most of the bank's offices closed at 4 PM. As it turned out, a single transaction ground Barnett's two giant mainframe computers to a halt, according to Jonathan Palmer, Barnett's chief technology officer. "A coding error in a program caused our whole computer complex to 'hang up' ... That one transaction acted like a computer virus" by redirecting the computers from their appointed tasks. Barnett is working on new systems to avoid any repeat of Tuesday's troubles. "This should be an extremely rare occurrence," Palmer said. | A more detailed description of how the bug "redirected" their | computers and in such a way that the offending transaction couldn't | itself be located or help find the bug during the whole day would | be interesting. Other risks naturally include being a bank user | who customarily uses ATMs or uses different branches for convenience. Norm deCarteret IBM Information Network Tampa FL
The ocean liner QE2 had its hull damaged sailing near Martha's Vineyard. Nautical charts of the area (made in 1939) show a shoal at a depth of 39 feet (surrounded by readings of 85 and 90 feet) near where the ship hit something. The ship's draw is listed as 32 feet, which should have left seven feet to spare. (Of course, it is not known if this is what was hit, or if the pilot, a local pilot brought on board to navigate coastal waters, would have tried to stay clear of that ledge even if there was supposed to be seven feet clearance.) The entire area has been known as a dangerous one for ships for centuries, though the QE2 was in a standard navigation channel, heading for NYC. An article in the NY Times today (12 Aug) points out that the nautical charts are based on a "sonar technology that may have overlooked higher peaks or boulders on an underwater ledge", described by an NOAA spokesman as "hit or miss". He said "It is possible that the survey missed a shallower depth, that the survey passed around it and didn't see it." It surprises me that surveyors, when finding a steep shoal like this, 50 feet higher than the surroundings, would not look specially for its tip. This points out the danger of digitizing real world data onto a fixed grid. Today's article in the Times (by Felicity Barringer) ends by noting that "at least two of the ship's three electronic navigational systems were operating at the time" of the accident. -John Sullivan@geom.umn.edu
The Aug 1st issue of the Economist has an editorial and article on "Stupid Computers". They say attempting to pass the Turing test is a bad idea, because computers think differently than people. Computers and people can complement each other. American Express, having computerized its credit card division, can now hire humans who are good at dealing with people (instead of at number crunching), and can give them more freedom to solve customers' problems (with the computer's help). The article starts out: Every customer has at least one horror story to tell of a company or a government deptartment that is unable to stop sending wrong bills, or to correct an address, or to divulge a piece of information "because of the computer". Teh brainless obstinacy of some machines has made them great allies of bureaucratic solution blockers. So the very thought of giving machines more responsibilities will send chills down many spines. Fear not. Companies are findin that the more intelligent machines are allowed to play to their strengths. the more they reduce human obstinacy. However, it does conclude on a note of fear: Someday someone will inevitably go too far. Bankers, for example, are talking about using artificial intelligence to enable their people to sell financial products too varied and sophisticated for the salesmen to understand. Now that is an intelligent idea that could leave someone looking very stupid indeed. I don't see qualitative difference between this scheme and the one that allows American Express to hire people who don't understand the number crunching. -John Sullivan@geom.umn.edu
* Space Station: NASA's Software Development Approach Increases Safety [Risks]
and Cost Risks. US Government Accounting Office. Report to the Chairman,
Committee on Science, Space, and Technology, [U.S.] House of
Representatives, GAO/IMTEC-92-39. June 1992.
[The above title was DISAMBIGUATED by the insertion of "[Risks]" by PGN.
The first time I read the title, it seemed to suggest that the approach
increases safety. The text clearly indicates that is NOT what was meant.]
* Space Shuttle: NASA Should Implement Independent Oversight of Software
Development. US Government Accounting Office. Report to the Chairman,
Committee on Science, Space, and Technology, [U.S.] House of
Representatives, GAO/IMTEC-91-20. February 1991.
Copies may be obtained directly from the GAO (P.O. Box 6015, Gaithersburg MD
20877), or through James Paul (paul@nova.house.gov — if his system is up!).
These are relatively incisive and useful reports. Thanks, James! PGN
[Jon Jacky reproduces _Seattle Times_ item on a ship that leaned
left then right, the article then says:]
> Tacoma Boat, which built the Dona Karen Marie, [...]
"Tacoma" seems to have something with to do with bad oscillations :-)
Cristobal Pedregal Martin, Computer Science Department, UMass/Amherst MA 01003
[It certainly Narrows ones thinking! PGN]
I was working as a programmer for a military command center, the kind with
large screens around the walls which display current status of whatever. The
system was a custom job with custom software, but was fairly stable (no
outstanding software problem reports, no recent modifications). Normal
operations 24 hours / day, 7 days / week.
One Monday morning about 0600, the system crashed. No problem. The operator
initiated warm start on the hot backup system and dump procedures on the failed
machine; back on-line in less than 3 minutes (and called me, midnight shift
programming support). A few minutes later the alternate system crashed. What
to do? (The dump takes about 11 minutes. If we abort the dump to get on-line
as fast as possible, we lose any chance of finding out why the first crash
occurred. And the primary system may go down again if we have an unrepaired
hardware problem. But since both systems crashed within minutes of each other,
its probably a software problem, so if I don't get the dump, we have ZERO
chance of finding out what happened.) Call the command post for permission to
complete the dump. Denied. Abort the dump. Reboot the primary. Initiate
dump on the alternate. The primary crashes again. Reboot the alternate.
Initiate dump on the primary. The alternate crashes again. This time we get
permission to allow the dumps to complete. Reboot and back on-line. By now,
it's after 0700.
Start analyzing what happened. Trace the problem to a data input routine.
Hmmmmm. Seems like its overrunning the buffer and trashing an adjacent data
structure. Can't be, the buffer is already larger than the physical limit on
the terminal (an IBM 2701 - a then modern but now ancient IBM Selectric
ball-type typewriter rigged as a computer input device). Quick fix: move the
adjacent data structure further away from the buffer, re-assemble (Yes,
Virginia, we had computers before we had compilers. What's that, you little
snot? Yes, I did work on them and no it was not before Christ.), bring the
alternate to "hot backup" status and do a switchover. Take a deep breath and
start figuring out WHY it happened, because the General has missed his Monday
morning briefing and is going to want to know whether he cna count on his
primary command and control system or not.
Hit a stone wall. Couldn't find anything wrong with the code. So I put an
alarm in that input routine, took my chewing out and went on with life. Two
weeks later, my alarm went off. The system didn't crash because I had moved
that fragile data structure, but it would have if I hadn't moved it. The alarm
also triggered an on-line dump and, when I checked it, sure enough, that same
terminal had overrun its buffer again. But it can't! The buffer is 128
characters deep and the IBM 2701 is only 85 characters wide; you HAVE to enter
a carriage return to continue.
Well, not quite. I finally made the connection between one particular Major
inputting data for the General's morning briefing and the alarms. It seems
this Major had figured out that the display screens could handle lines 132
characters long even though the input devices could only provide 85. So when
he got to the end of a line on the terminal, he would grab the typewriter ball,
drag it to the left, manually roll the paper forward and keep typing. As long
as he was entering less than 128 characters, everything was ok. But when he
went over that, ...
OBSERVATION 1: A user will do anything (s)he can think of to get the job done.
OBSERVATION 2: They are usually more creative than we are, i.e., they think of
things we don't.
Jeff Hull, 1544 S. Vaughn Cir, Aurora, CO 80012 303-977-1061 hull@den.mmc.com
>... Lewis had put a "conditional statement" in the computer's software >which caused it to stop functioning at claim number 56789, the judge >said. The law firm paid another consultant $7,000 to fix the problem. > [Once again this brings up the concern of people thinking that anything that > happens in a computer system that wasn't expected by the end users is a bug. > I'd like a job where I got paid $7000 to remove a "conditional statement." > John Kriens jkriens@decoy.cc.bellcore.com] I all fairness, let's note that the new consultant was probably expected to vet the code for any more unexpected surprises. Personally, I think $7,000 was pretty cheap considering all the ways you can hide a whammy in code.
Under (price) pressure, failures certainly become more common: >Beware of high pressure without passive safety devices! This is the same problem as our perrenial fly-by-wire discussion, so I'll let that part of the message stand. I would like, however, to raise another point: >The pump was controlled by a ZEOS 386 clone via a serial line. [...] >They had had problems with the clone in the past; most of which were believed >related to the Extended Memory Manager. Ah. Doing real-time control under DOS or Windows. I couldn't imagine speccing a DOS based system for real-time control where system failure could lead to physical harm. I'm even leary of the use of an AT bus based machine: given the cost of the rest of the system and the risks involved I'd suggest buying a professional quality real-time control system rather than using this sort of hobbyist equipment. Yes, we use DOS systems as part of real-time control systems, but only for man-machine interface (monitoring, supervisory control, and so on). And we typically buy the PC from one of the vendors that sells industrial quality equipment. Yes, a 19-inch rack-mount passive-backplane box may cost several times as much as a generic clone, but it's worth it. If you MUST use a PC, there are real-time systems available: QNX, LynxOS, iRMX, and so on. iRMX even comes with a Windows-capable compatibility box, so you can run your DOS and Windows software... though I'd strongly recommend against it, at least while the experiment is under way. (note that this is not a panacea: the (presumably professionally implemented) real-time control system in the pump itself apparently failed as well... but at least it does give you a fighting chance at producing a reliable system) === On another note, I'm concerned about the possibility of "frequent" mistakes in Southwestern Bell's Caller-ID system. I'm strongly in favor of Caller-ID as a concept, and have said so here and in TELECOM digest in the past. I did, however, assume that it would be approximately as reliable as the rest of the phone system: wrong numbers that are not the result of misdialing are quite rare. If there's a problem in Call-Return shared by Caller-ID (which is possible though not obvious: the dialler at the CO that Call-Return uses might be at fault) then I would certainly want it fixed BEFORE it goes on line. I'd even support pulling Call-Return until the problem can be resolved. Pat Townson of TELECOM Digest has apparently seen no signs of this up in Chicago, so it may be a local problem. Southwestern Bell has not impressed me with their competance in the past. === As for voice-mail systems, a simple "and dial 0 for an operator" entry in the menu would solve most of the problems people have. I *like* using these systems, but occasionally I get lost in a maze of twisty little options (say, for example, the menu item I'm used to selecting has been changed) and would dearly like the ability to bail out. Peter da Silva, Taronga Park BBS, Houston, TX +1 713 568 0480/1032
Please report problems with the web pages to the maintainer