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…
From: <T3B%PSUVM.BITNET@WISCVM.WISC.EDU> (Tom Benson)
Subject: Computerized Voting
After the election, a representative random sample of precinct boxes
would be counted by hand, and matched to the electronic tally, just to
audit accuracy.
I'm afraid of the seeming reasonableness of this "solution". If we are
using the audits to look for fraud in ballot-counting, then "who chooses the
`representative random sample'" becomes the interesting question; votes,
unlike decaying nuclei, are not uniformly distributed. People who tend to
vote for candidate X might live in certain precincts (i.e., black people);
might vote at certain times of day (9-to-5 working people); might vote by
absentee ballot (older people). If I had the ability to "cook" a voting
machine, I might just as easily have the opportunity to cook the "random
audit selector".
If we are using the audits to detect failures, rather than fraud, then we
must still check every machine and for all times of day, for the same
reason: to avoid disenfranchising a segment of the electorate, whether
inadvertently or intentionally. Every vote counts: recall the senatorial
race in NH decided by 1 or 2 votes a few years ago, or (closer to where I
now live) the East Palo Alto incorporation election, decided by 13 votes and
still being challenged in the courts.
Another thing: mikemcl@nrl-csr (Mike McLaughlin) suggests
The "receipt" would contain the date, time, machine number, serial
number of the vote, and name the candidates and issues for or
against whom/which I voted. It would NOT list my name.
No, but the poll watcher who saw you vote and wrote down the machine
number and time of day next to your name wouldn't have much trouble
matching the receipt, if you ever returned it.
I'm not saying that non-computerized systems are immune to error;
but be careful that a technology that appears value-neutral (such
as "representative random sampling") isn't ignoring political reality
or creative dishonesty.
I find the various suggestions to back up computerized voting with physical ballotting as taking steps in the wrong direction. Certainly we can reduce risks by backing up computer/automated systems with human beings, where feasible, but to keep around a bunch of punched cards in order to ensure the integrity of electronic voting seems to me to be the wrong approach. Larry Polnicky, Honeywell Information Systems, McLean, Virginia.
This is not a VOTIVE message; I have broken my vow to remain silent while watching the schemes for voting integrity get wilder and less controllable. DEVOTED as I am, I can no longer keep silent. My main point here is that as more complex mechanisms are added to control or audit the integrity of the voting process, the more vulnerabilities are likely to be introduced, and the less controllable the whole process is likely to be. Nancy Leveson makes a similar point in her survey paper on software safety: as complexity is added to control safety, the more things get out of hand. I am prompted to drag out my old Albert Einstein quote — for our newer readers: Everything should be made as simple as possible, but not simpler. There is intrinsic complexity in the voting process. A voting scheme with no controls is easy to misuse. A voting scheme with many controls can also be misused, but in different ways — perhaps requiring greater subtlety. Furthermore, such a computerized system must be used and administered by ordinary mortals; however, elaborate procedures tend to break down or be vulnerable. Furthermore, remember that many of the programs controlling elections are written by just a few software houses. The potential for Trojan-horsing around is enormous. A gifted system programmer can pull off all sorts of things. We have already seen cases of data changed on the fly in computer-counted ballots, even with consistency checks and audit trails (which themselves can be fudged). One can dream up all sorts of checks and balances — formal verification of the algorithms, crypto seals on the stored code for integrity, encryption schemes to detect added ballots, and so on, but there are always points of vulnerability. So, in the discussions here, please let us try to be realistic! Peter
WASHINGTON (UPI) - A computer glitch enabled a man to get away with $140,000 in $10- and $20-bills in a weekend run on 16 automatic teller machines in the nation's capital and its Virginia suburbs, the Secret Service said Wednesday. Michael Caputo, 31, of Fairfax Station, Va., admitted in federal court Tuesday to using a stolen VISA credit card to make more than 400 withdrawals from the money machines last October. The withdrawals represent the largest fraud committed agains VISA with an automatic teller machine, officials said. "Why didn't someone else in line notice it?" asked John Magaw, a Secret Service agent. "It's very bizarre. All of a sudden this guy realized how good he had it. His pockets just weren't big enough. The machines just weren't programmed to stop." Caputo was photographed by monitors at the 16 mechanized tellers receiving $300 during each transaction - at times smiling while other times holding bags of money. "Normally, you can't take more than $200 at a time, and (most machines) will not allow you on nights and weekends to go beyond a certain limit," Magaw said. "Somehow, the safeguards broke down to allow for that to happen." Magaw said that Caputo apparently used the VISA card at two banking institutions. He said that the two computers did not "blend together," and allowed him to take large amounts of money without being detected. "It's like having a Chevrolet and a Buick and putting a carburetor from one on the other," Magaw explained. "You may get it to work, but it just doesn't quite go together. There's glitches that have to be worked out."
He emptied the machine of several thousand dollars, put it all into a
paper bag, and left. The next day he went to the main office of the
bank, saw the manager, and said, "Your teller machines can be robbed."
The manager of course said this was impossible, at which point my
friend dumped the bag of money on his desk and said, "You won't be
wanting this back, then." The machines were down for the next several
days...
Anybody have some stats on these things? I seem to recall seeing
something that the banks are still losing money on them, but it didn't
show any figures. Anyone have any data on this? I'm sure that given
a few hours most people on this list could come up with at least one
way to rob the machine down on the corner.... (let's not discuss the
methods in detail though; I'm sure the banks have enough problems
without us advertising ways to steal from them).
--Dave Curry
[I have various inside stories about the extent of fraud, but the
victimized institutions seem to keep pretty quiet. They don't want to
lose customer confidence and customers. Besides which, they can simply
up the rates to amortize the losses. Who cares, especially if the
customers don't even know? (OK. I care.) PGN]
The following message, which was in the tcp-ip list from SRI-NIC was in
discussions of Internet (ARPA/MIL) Mailbridge performance. I think it is
interesting from a RISKS point of view. How much does the computer
science, aerospace, etc industry/research depend on the Internet?? What are
the consequences of a long-term failure of ARPAnet? How suceptable is the
ARPANET to terrorism/natural disaster/etc. ?
------BEGIN INCLUDED PORTIONS ------
>Date: 3 Mar 1986 17:03:11 EST
>From: Edward A. Cain <cain@EDN-UNIX.ARPA>
>Subject: Re: Mail Bridge Performance
>To: gross@mitre.ARPA (Phill Gross)
>
>Phill,
>
>Thanks for the summary of mailbridge traffic. I think it does partially
>explain why performance is so awful at times thru the mailbridges. The
>correlation with school schedules is interesting, too, and probably a better
>guess than any I've heard recently.
>
>There is one other important consideration. Performance on the ARPANET alone
>has been terrible at times. For example, ICMP ECHO and ECHO REPLY round-trip
>measurements between east and west coast hosts were averaging 18 seconds on
>Feb 3-4, with tails of the delay distribution out to 37 seconds, as measured
>from DCEC (via arpanet) and at BRL (via milnet). Delays were very high
>again during the Feb 12-14 time period. Even worse, on Feb 20th, one hour
>in the afternoon the roundtrip delay from DCEC to the arpanet interface of
>the ISI mailbridge was 30-40 seconds, and from DCEC to the arpanet
>interface of the SRI mailbridge the delays were 45-47 seconds during the
>same hour, with 90% packet loss!!!
>
>Usually, this kind of behavior on the arpanet is coincident with the outage
>of key lines or nodes in the arpanet. On Feb 20th for example, line 76
>(utah to lbl2) and line 76 (sri2 to collins) were both down most of the
>day because of flooded cableheads.!!! The loss of a key component in the
>arpanet seems to create serious congestion when the traffic goes up. And
>congestion is noticed quickly by the mailbridges, which are among the
>busiest arpanet hosts in terms of both packets sent and connection blocks
>used (in the IMP).
>
[REST OF MESSAGE TRUNCATED]
>Ed Cain
The recent message about flooded cableheads and the potential vulnerability
of the internet to loss of critical components made me wonder:
How many IMPs are there on the ARPA side? [Hundreds]
How many on the MILNET side? [Hundreds]
Where are they? I would assume that at least the MILNET IMPs are
in secure areas. [Not necessarily, but they are under the
control of DCA and BBN. That helps. PGN]
Tom Perrine
Please report problems with the web pages to the maintainer