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…
I have followed with interest the recent discussions of vote-counting errors in
Durham NC, Yonkers NY and elsewhere. Perhaps the following may be of interest.
It is a discussion of a specific vote counting problem in a jurisdiction where
I served until last year as an elected official.
Lawrence Kestenbaum, 506 S. Albany St., Ithaca NY 14850 (607) 272-7750
[grad student at Cornell University in City and Regional Planning
(specializing in Historic Preservation), an attorney licensed in Michigan
(number P34957), and a former Ingham County Mich Commissioner, elected from
the 8th District in 1982, 1984 and 1986. Nothing in this message is private
or privileged information.]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Some of the recent problems with inaccurate election-night vote tallies can be
traced to the badly-handled interface between computer and manual systems.
Non-electronic vote counts, for example, are mistyped on computer screens
during the hectic atmosphere of election night. Of course, when the computer
system plays the dominant role, the difficulties with the non-computerized
parts are even greater.
While most of the Northeast still votes on the old-style lever machines, the
Midwest — Michigan at least — has largely moved to computer punch card
ballots. Punch cards have certain advantages: in the event of a recount, a
tangible, anonymous record exists of each voter's choices. By contrast,
recount lawyers are often able to find whole voting machines whose votes must
be excluded from the count because of mechanical problems, thus disfranchising
anyone who voted on that machine. Other problems are possible, but all in all,
results from punch card jurisdictions are regarded as being much more 'firm'
and resistant to being altered in recounts and challenges. At the same time,
it lulls political people into a sometimes unjustified faith in
computer-generated vote tallies.
When I served on the county board in Ingham County, Michigan (1983-88), we had
a mixed system. The choice of voting method was made individually by the 21
townships and cities within the county. Thanks to strong persuasion by the
county clerk, almost all of the 250 or so voting precincts in the county voted
on punch cards. The remaining five precincts, in four small jurisdictions,
used voting machines; absentee voters in those five precincts used punch cards.
In no other part of the county were absentee votes counted separately. Under
contract with most of the punch-card jurisdictions, the county provided the
materials and organized the ballot counting process.
The software which aggregated and reported the votes for the county, and also
automatically generated all of the official statements to be attested to by the
Board of Canvassers, did not allow for the entry of non-computer precincts.
Thus, the county clerk's people had to break into the program and override its
security features in order to input the numbers for the five rogue precincts.
The risks here should be obvious! Invariably, this task was postponed until
very late at night, when the operators (who normally worked 8am to 5pm) were
extremely tired. More than once, as I recall, this led to errors in the
overall totals, though none which changed the outcome, and all were corrected
by the following day.
After a few years of this, the county clerk (with full support from the county
board) mounted a major effort to corral the five remaining precincts. He
succeeded with all but one of them, the City of Leslie. So, on a smaller
scale, the problem — and RISK — continues.
Lawrence Kestenbaum, wclx@vax5.cit.cornell.edu
Lawrence Kestenbaum's message gives an interesting first-hand account. However, there is much debate in the election computing community about the relative tamperabilities of machine-readable cards (punched or mark-sensed), lever machines, and direct-entry screen menus. Punched cards give results that are more or less repeatable (ignoring the hanging chad problems). But they are subject to tampering BEFORE any votes are ever tabulated (removed cards, added cards, multipunched cards, hidden prepunches, trick punches that unleash Trojan horses, etc.), which can make the repeatability argument moot. The RECOUNT would mask the prior fraud and even add apparent credibility! The fantasy that there is a CORRECT anonymous physical record is very tricky to convert into a reality. (There are different vulnerabilities in the other types of systems, such as the presence of perfectly repeatable but hidden and probably undetectable Trojan horses in the direct-entry systems — especially in proprietary systems. See earlier RISKS...)
I worked on custom military design for almost 7 years recently.
I have two anecdotes to relate regarding recent RISKS discussions:
1) Some colleagues and I endeavored to design the operating systems for the
latest in a series of custom large-control-word multi-processor signal
processors using a purely waterfall model. We insisted on writing the design
spec before writing any code, and finalizing the design spec (after initial
review) down to the individual bit level. We then wrote pseudo-code for all
modules, and peer-inspected those. Finally we wrote the code with strict
commenting standards and assembled it, then peer-inspected that. Finally we
wrote module tests, simulated those, then string tests, simulated those, and
one day the hardware was off the drawing boards and in the lab. The results?
The development cycle, with full waterfall design method and full regression
tested test database, was only 2 months over schedule (former efforts on
similar jobs ran up to a year over). The norm for getting a basic operating
system up and running in a lab environment without bells and whistles was 6-9
months — it took us a week. Overall savings in development/debug time --
probably at least 40%. Overall savings in down-the-road software maintenance
-- untold. So let me say that I am skeptical at best when someone tells me
that waterfall design should be dumped on large involved custom
software/hardware projects.
2) I had a chance to have a several-hour chat with a Navy commander who headed
the technical management on the Navy end of our several-hundred-million-dollar
project. He noted that the average time for delivery of a large military
contract now was 8 years and growing, and that the results were far from
satisfactory, particularly in the RISKS area. He blamed much of this on
government procurement and the rampant cover-your-ass overspec'ing that went
on. He proposed a system wherein the contractor(s) would study and prototype
for some time, a year for example, then come back and note the 10% of the job
that they felt was overspec and would cause serious money, time, and risk
problems. Independent government negotiators would then attempt to take these
portions out of the contract if they were indeed overspec, but the contractor
would suffer little or no degradation in the original price quoted for the
contract for their having pointed these overspecs out. He estimated the
average deliverable time would go down to about 5 years, and the products
delivered would be slightly cheaper and much more reliable. He also was sure
his ideas would never fly at the Pentagon. :-(
Curtis Jackson @ Adobe Systems in Mountain View, CA (415-962-4905)
uucp: ...!{apple|decwrl|sun}!adobe!jackson
The New York Times today (12/1/89) features a story by Jeff Gerth that says
that the modernization of a Pentagon computer system used for general data
processing is a billion dollars over budget, and far behind schedule. And the
congressional report released about this system says that Pentagon computer
systems have experienced "runaway costs and years of schedule delays while
providing little capability."
Charles A. Bowsher, the head of the General Accounting Office, says that
problems with the Pentagon's accounting system may impede efforts to reduce
spending in the Department of Defense because of inaccuracies in the data used
to manage the Department.
Today's New York Times article reports only on cost overruns and delays in
accounting and data-processing systems used by the Department of Defense and
the services. But there are also these examples one could add to the list:
* The C-17 cargo plane being built by Douglas Aircraft
has a $500 million cost overrun because of problems
in its avionics software, and the software contractor
has been fired, according to a member of Congress.
* The B-1 bomber still needs more than $1 billion to
improve its ineffective air defense software. The
B-1 was originally sold as a "penetrating bomber,"
meaning it was supposed to be able to penetrate
Soviet air defenses. Because of problems with its
computer software, however, the B-1 is not expected
to be able to penetrate Soviet air space, and that's
why the Air Force is asking for the B-2 (which has
its own software problems). (At one point the B-1
electronic countermeasures software created what
was called a "beacon" effect, meaning it would actually
alert Soviet air defenses and give their radars
a clearer signal of the aircraft than they would have
if the airplane's systems had been turned off.)
* The software for the modernization of the Satellite
Tracking Control Facility is about seven years behind
schedule, about $300 million over budget, and will
provide less capability than what the original con-
tract called for.
* The modernization of the software at NORAD headquarters
is about $250 million over budget, years late, and
still non-operational.
* The Airborne Self-Protection Jammer (ASJP), which
is an electronic air defense system installed in over
2,000 Navy fighters and attack planes, is $1 billion
over budget, four years behind schedule, and, accord-
ing to a Navy report, is only "marginally operationally
effective and marginally operationally suitable."
As General Bernard Randolph, commander of the Air Force Systems Command, said
in February, "We have perfect record on software schedules--we have never made
one yet and we are always making excuses."
Gary Chapman, Executive Director, CPSR chapman@csli.stanford.edu