Re: Shamos rebuttal -- re-visit

From: Ron Crane <voting_at_lastland_dot_net>
Date: Thu Apr 14 2005 - 15:59:44 CDT

On Apr 12, 2005, at 2:51 PM, Alan Dechert wrote:

> I wrote the following last year to the voting-project list. I was
> hoping to get some good input but for some reason I got very little
> feedback. I want to re-visit this because someone wanting to rebut
> Shamos found this article and wants to submit it to officials in PA.
>
> Please, if some of you could sharpen your pencils and go over this,
> I'd appreciate it....

Here you go! The first section contains my (multitudinous) criticisms
of Shamos's article. I have omitted most criticisms that overlap yours
or those of others who've responded to your message. The second section
reviews your article.

Please examine my criticisms and integrate the useful ones into your
article. Then let's all re-review the updated article.

Thanks for the opportunity to comment!

Ron

------------------------------------------------------------------------
------------------------------------------------------------------------

----
Criticisms of Shamos's Article
1. [placeholder]
2. Section 1 implicitly conflates error rates on voting machines  
("0.2%") and fraud. But they're far from the same thing. Errors are, by  
definition, candidate-neutral, and thus should not, on average, affect  
election outcomes. Fraud is, by definition, directed precisely at  
affecting outcomes. Thus, a given rate of fraud is a far greater worry  
than the same rate of error.
3. "Voter[s] may eschew voting machines completely and cast a paper  
absentee ballot." s.1. This ignores three important factors: (a)  
Election integrity depends upon everyone's vote being properly counted,  
not just the votes of the few members of the public sufficiently  
concerned about election integrity to avoid DREs; (b) absentee voting  
requires significant forethought; and (c) absentee ballots are usually  
counted electronically anyway.
4. "WIthout a single verified incident of successful tampering". s.1.  
Because of DREs' design, and the procedures surrounding their use, the  
only reasonable ways to discover tampering are (1) if it's outrageous  
or (2) if a tamperer squeals. Even the Max Cleland race wasn't  
outrageous enough to trigger a full-scale investigation: Cleland polled  
49% to Chambliss's 45% a few days before the election,  
http://www.usatoday.com/news/politicselections/2002-11-03-state-polls- 
usat_x.htm , then "lost" 53% to 46%. The election was Georgia's first  
using Diebold DREs.  
http://www.thenation.com/doc.mhtml?i=20040816&c=7&s=dugger . As for  
squealing, what would motivate a tamperer to squeal? Black-box testing  
will discover only the most incompetently-designed cheats.  
"Certification" is generally meaningless, since usually nothing  
prevents vendors from replacing "certified" code with new code  
containing "bug fixes"  and Trojan Horses.
Further, the "it's worked so far, so it'll continue to work" argument  
is meaningful only in the context of continuous systems. That is, it's  
reasonable to say, "This bridge has stood for 15 years. It's safe."  
Why? Because, in 15 years, a bridge successfully will have withstood  
the vast majority of the stresses ("operational paths") it's likely to  
encounter on any given day. Software, on the other hand, is a discrete  
system. That you've exercised the "it works OK" operational path  
trillions of times says nothing whatsoever about the existence of a  
"steal the election" operational path.
5. "Purely hypothetical scenarios." s.1. First, this argument assumes  
its conclusion. We do not know that no fraud has been perpetrated using  
DREs (or other voting systems using electronic casting, tabulation,  
and/or canvassing), and some recent events (e.g. the Cleland election,  
the 2004 Presidential election  
(http://electionarchive.org/ucvAnalysis/US/Exit_Polls_2004_Edison- 
Mitofsky.pdf)) strongly argue the opposite. In the 2004 Presidential  
election, voting conducted using hand-counted paper ballots matched  
closely tracked exit polling, while voting conducted using  
computer-assisted or mechanical technologies (including DREs,  
mechanical voting machines, op-scan systems, and  
electronically-tabulated punchcards) did not.  
http://electionarchive.org/ucvAnalysis/US/Exit_Polls_2004_Edison- 
Mitofsky.pdf (table 7).
Second, we examine hypothetical scenarios to explore reality. Until a  
certain beautiful September day, it was "purely hypothetical" that 19  
terrorists would hijack 4 airliners and fly them into 3 buildings. That  
a risk (assumedly) has not been realized does not mean that it doesn't  
exist.
Third, the burden of proof should not be placed on voting system  
opponent to prove fraud, but on vote system proponents to prove its  
absence. Why? Because defective voting systems endanger the body  
politic. Just as the FDA places the burden on drug manufacturers to  
prove safety and effectiveness  because bad drugs can harm the body  
personal  so should we place the burden on voting system proponents to  
prove the safety and effectiveness of their systems.
5. "Extremely accurate sense of how the community is going to vote",  
"smell of irregularity", etc. s.1.1. See Cleland/Chambliss. Also, much  
self-serving partisan work has been done to discredit exit polls in the  
aftermath of President election 2004. There are no longer any  
reasonable checks along these lines on cheating elections equipment.
6. "Software in the machine survives", s.1.1. So what? You can test it  
'till the cows come home, but a properly-constructed cheat will work  
only on election day. Further, it's vanishingly unlikely that anyone  
will bother, or that those who would bother will be allowed to do so  
(see, e.g. how the Ohio recount cases have been handled).
7. We trust our lives to software, why not our votes? Because the  
motivations involved in the two situations are quite different. The  
motivation to "cheat" (that is, murder people) with flight software can  
only be that of a terrorist, a murderer, or an insane person, and it is  
overwhelmingly likely that such a motivation will be harbored by only a  
single person on a project, whose chicanery is thus likely to be caught  
by others. The motivation to cheat with voting software encompasses not  
only individuals, but whole organizations. Further, flight software is  
subject to far more rigorous specification, implementation, review, and  
testing procedures than voting software. [I know this is true. Can  
someone please provide a few reliable cites for it.]
8. "[T]he republic will survive if a president is elected who was not  
entitled to the office". s.1.1. For awhile, and only in a manner of  
speaking. A republic repeatedly dealt this hand is no longer a  
republic, but a dictatorship run  invisibly  by those who count the  
votes. Is this an appropriate vision for America? [I would give this  
point a relatively high profile, since Shamos evinces an apparent lack  
of concern for the central characteristics of democratic republics].
9. Section 1.2(4), subcase 2 on vendor-provided malicious code misses  
the point. The software shipped in a DRE need not contain  
"database[s]", nor need it know "the precise hours during which all  
future elections are to be conducted." An intelligent cheating vendor  
will write its software to accept instructions and/or additional  
software transmitted by wireless (e.g. WIMAX) or other (e.g. power-line  
broadband ("BPL")) means. The machine will then cheat as directed.  
Further, a DRE need not use a wireless transceiver  whose  
transmissions conceivably could be detected on election day. It needs  
only a receiver that can decode cheating instructions broadcast via the  
appropriate medium. Since WIMAX, for example, has a range of 30-ish  
miles, and BPL several miles, the cheater can ply her trade from almost  
anywhere. Finally, the range of such networking technologies will only  
increase over time, quite likely making such creating practical even in  
isolated communities.
Or, a cheating vendor could use Shamos's "solution" (item 22, below) to  
feed cheating instructions to the DREs.
10. The strawman that compares vendor cheating using DREs and  
Goldfinger, s.1.2, in particular the comment beginning, "The reason is  
that adults eventually develop the ability to distinguish fact from  
fiction...", merits the use of a nuclear-powered flamethrower, but I  
suggest something milder that makes the point that such arguments  
actually promote the continued use of insecure machines.
11. "The Omniscient Hacker" in s.1.2.1 could be a vendor using cheating  
software in the manner I noted in item 9. As for "test[ing] the machine  
during the election by feeding it votes in a manner indistinguishable  
from regular voting", there are several issues. First, this test must  
actually be performed on schedule and in a manner such that the vote  
stream is truly indistinguishable from regular voting. If the DRE is a  
networked device, it might not be possible to do this without cueing  
the DRE to the fact that it's being tested. Or perhaps the DRE  
"helpfully" provides a "test mode"  most elections officials would  
have no idea that this could be a cue to record votes honestly [1].  
Second, elections officials must actually believe, and act properly  
upon, the discovery of cheating. Far too often elections officials  
treat anomalies (such as the one in which 600 voters somehow cast 4,000  
votes for a Presidential candidate in Ohio  using DREs.  
http://sfgate.com/cgi-bin/article.cgi?f=/news/archive/2004/11/05/ 
politics1149EST0515.DTL ) as "glitches", and merely remove the  
offending machine(s) from service. This kind of response would have  
essentially no effect upon cheating as described in item 9, above. But  
what reasonable response is there? It's election day, the machines are  
cheating, and what is an official to do? Shut down the polls? There  
really is no practical response.
12. Section 1.3, which says, "Congress has no power to determine the  
manner in which presidential electors are chosen other than to specify  
the time and date of their election" and its following assertion of  
unconstitutionality are very likely incorrect. Art. 5 of the 14th  
Amendment explicitly empowers Congress to enforce its provisions, one  
of which happens to be the equal protection clause. This was the very  
clause that the Supreme Court invoked to stop the Florida recount in  
Bush v. Gore  a presidential contest. This criticism also applies to a  
similar assertion concerning the "Protecting American Democracy Act of  
2003" in section 2.1.
13. Section 1.4 ignores the possibility of an item 9 malware loader.  
Even assuming that the vendor makes a DRE's actual source available for  
inspection, and that it actually loads into the DRE an executable  
honestly derived from that source, a malware loader could still be  
contained in an FPGA or ASIC [2]. Such a loader would be programmed to  
detect a cheating signal (broadcast via WIMAX, etc.). When it does so,  
it would issue a specified interrupt to the DRE's CPU, which would halt  
it at a known location in memory. The loader would then receive the  
cheating code, load it into memory, modify the instruction following  
the CPU halt point to contain a jump to the cheating code, and instruct  
the CPU to resume operation. The CPU then would begin executing the  
cheating code. Detecting this kind of malware loader requires a  
complete analysis of the DRE's hardware.
Further, this section underestimates the amount of code that might  
contain malware. Malware need not be confined to the code that directly  
parses touch-screen input. It could be involved anywhere along the  
chain between the presentation of the choices to the voter to the  
recording of the results.
14. Section 1.5 implicitly argues that DREs are suitable for America  
because India has chosen to use them nationwide. Proper response: India  
adopted them; so?
15. Section 2 implicitly blames the invalidity of 337,297 ballots cast  
in Taiwan's 2004 presidential election upon the use of paper ballots,  
saying, "Surely if the voters could rely on the paper ballots to be  
counted properly this result could not have occurred." Shamos provides,  
however, no breakdown of the reasons behind the declarations of  
invalidity, and does not address the potential contribution of the  
"Million Invalid Ballot Alliance", which asked voters to reject both  
candidates by spoiling their ballots.  
http://www.atimes.com/atimes/China/FD02Ad01.html ;  
http://news.bbc.co.uk/1/hi/uk/3560355.stm .
16. Section 2.1 implicitly argues that voting is similar to financial  
transactions, and, since financial transactions successfully have been  
computerized, voting successfully can be computerized as well   
presumably through the use of DREs. This section ignores six key  
differences between financial transactions and voting.
First, financial transactions form a closed loop whose correctness can  
be verified in its entirety  such as by the comparison of receipts and  
periodic statements, double-entry accounting, the comparison of inflow  
and outflow records between multiple entities, etc. Voting, on the  
other hand, is an open-loop process in which the voter must simply  
trust that her vote is properly counted [3].
Second, each participant in a financial transaction has a strong  
incentive to verify its correctness. This incentive is largely lacking  
in voting. While a small number of highly-motivated voters may wish to  
verify whether their votes properly were counted, most voters don't  
care enough to do so.
Third, there is strong legal recourse for financial fraud, including  
restitution, financial penalties, and commonly-enforced criminal  
sanctions. In contrast, there is little real legal recourse for vote  
fraud. Generally election contests must be made within extraordinarily  
short time frames, and must overcome high evidentiary hurdles. For  
example, litigation surrounding Ohio's 2004 presidential election  
hardly got off the ground before Congress seated Ohio's electors,  
making the election irrevocable.
Fourth, financial attacks generally are waged by single hackers, not by  
the banks that conduct the transactions. The main concern with  
computer-related vote fraud, on the other hand, is not hackers, but  
vendors.
Fifth, financial transactions are repeatable, money often can be  
reclaimed, and a certain level of loss can be recovered by raising the  
prices charged to conduct the transactions. Elections, in contrast, are  
not repeatable, votes usually cannot be reclaimed, and vote loss cannot  
be compensated through other means.
Sixth, and finally, the software involved in financial transactions is  
generally very carefully reviewed and controlled. [Can someone provide  
some cites for this proposition?] The software involved in voting has,  
to date, often been handled extraordinarily sloppily.
17. Section 2.2 says that "The Federal Rules of Evidence give equal  
weight to electronic records in court proceedings as they do to paper  
ones". While it's technically true that the Federal Rules of Evidence  
allow the admission into evidence of electronic records in the same  
manner and for the same purposes as paper records, section 2.2  
whitewashes some critical differences in how courts actually treat  
electronic records. It's generally more difficult to get electronic  
records admitted into evidence than it is to get similar paper records  
admitted. A party wishing to admit electronic records must satisfy the  
court that, among other things, the computer system that generated them  
is "reliable", a process that sometimes requires the testimony of  
technical experts.  
http://www.snseurope.com/printer-friendly.php?newsid=2223 . And, even  
if admitted, electronic records might not weigh as heavily as paper  
records, since their trustworthiness depends upon the trustworthiness  
of the system that generated them. See, generally,  
http://www.usdoj.gov/criminal/cybercrime/usamarch2001_4.htm .
18. Section 2.4 conflates paper trails and paper ballots, ignores  
ballot-marking devices that maintain no electronic count, and argues  
that "each losing candidate will claim that the election was stolen  
from him by the machine.... If this is to be the case, why use voting  
machines in the first place?" That argument, of course, applies with  
equal strength to DREs. [I don't have the patience to give this section  
the fine-toothed review it needs. Will someone else do this?]
19. Section 3.1 ignores the possibility of certain presentation frauds.  
The "panel" might, for example, place its preferred candidate first, or  
show her name in bigger, bolder text than the others, or enlarge her  
selection area (and shrink those of the disfavored candidates) to make  
it easier to vote for her, or even occasionally omit the names of  
disfavored candidates.
Section 3.1 also requires an audit procedure that may often not be  
followed correctly, blithely assumes that an audit mismatch will result  
in "an investigation [being] launched", and blithely assumes that such  
an investigation will be effective. But section 3.3 says that "The  
administrative procedures concerning the handling of DRE machines...are  
usually not spelled out at all, or, if spelled out, then not circulated  
and not followed." Why, then, should we assume that the section 3.1  
audit procedure will be followed correctly? Further, even if this  
procedure is followed correctly, and an investigation of mismatches is  
launched, it is quite unlikely to do anything to repair the election  
that prompted it (see item 15, above). At best it will help prevent a  
future fraud. At best. Finally, elections officials are unlikely to buy  
the system this section hypothecates, since doing so requires dealing  
with three unrelated vendors (messy) and most officials (who are not  
trained in computer security) will not see the need.
20. Section 3.2, while endorsing open source requirements for "the  
ballot setup, display, tabulation and reporting sections of voting  
system code", expresses sympathy for security via obscurity for other,  
unspecified types of code, on the basis that such obscurity makes  
hackers' jobs more difficult. This approach makes open source  
essentially meaningless, since the undisclosed code may actually  
completely supplant the disclosed code. Since the undisclosed code is,  
well, undisclosed, you'd never know. Further, while security by  
obscurity may, indeed, make a hacker's job more difficult, hackers are  
not the chief concern; vendors are.
21. Section 3.5 ("parallel testing") is a good idea, but the machine  
under test could detect that it's being tested by noting the rapidity  
with which ballots were being voted, or the fact it received a burst of  
votes in the first, say, hour of voting, then none for the rest of the  
day. Persons craftier than myself might find other means to detect  
testing. Further, parallel testing works only if elections officials  
actually do it properly. Once a system has been in use "without  
problems" for awhile, vigilance is likely to wane, at which point the  
real cheating can begin.
22. Section 3.6 "separation of candidate names", touted as "the  
ultimate protection against malicious code", not only doesn't work, it  
provides a way to assist the functioning of malicious code, and even to  
assist its installation. First, as even Shamos admits, OCR (optical  
character recognition) technology would enable the DRE to read and  
interpret the images. Second, the graphic files presumably would be  
generated either directly by the vendor, or by using a program provided  
by the vendor. Either method would allow the vendor to insert hidden  
data into the image, either via proprietary headers, or via  
steganography. http://en.wikipedia.org/wiki/Steganography. A cheating  
vendor would, at a minimum, include in this data the mapping between  
image files and candidate names and parties, thus utterly defeating  
Shamos's scheme. But a craftier vendor might also include data  
indicating when to cheat, how much to cheat, how to detect when an  
anti-cheating test is being conducted, and so forth. Further, a vendor  
could even include code in the images, which the DRE could then load  
and execute. Finally, this approach doesn't impede the election-day  
broadcast fraud described in item 9.
23. Shamos generally ignores the possibility of tabulation and  
canvassing fraud. Even if DREs function perfectly, tabulation and  
canvassing fraud can corrupt the election.
[1] And, of course, there might be no good way to do a "dry run" except  
by use of "test mode": officials have somehow to prevent the "test"  
votes from contaminating the actual tallies.
[2] FPGAs and ASICs usually are considered hardware, and thus usually  
are implicitly exempted from code disclosure. FPGA- and ASIC-based  
malware would require access to a WIMAX or BPL transceiver. Both  
require a small amount of hardware that easily could be hidden inside a  
DRE. http://www.intel.com/pressroom/archive/releases/20040907net.htm ;  
http://www.theregister.co.uk/2004/07/02/intel_wimax/ (WIMAX);  
http://www.intellon.com/pdfs/INT5200_Ethernet_Ref_Design.pdf (BPL).  
Since WIMAX and BPL are 2-way technologies, it is possible to detect  
the transmissions from a DRE using them. A crafty, motivated vendor  
could doubtless find a way to disable the DRE's transmissions while  
still allowing it to listen for the cheating signal. Further  
developments in communications technology will only make this kind of  
cheat easier to implement and to hide.
[3] Technologies like VoteHere (Neff/Chaum) may help to change this,  
but it is not invulnerable to vendor-based attacks. For one thing, it  
doesn't prevent certain presentation attacks.
------------------------------------------------------------------------ 
------------------------------------------------------------------------ 
----
Review of Alan's Response
Overall this is a good response in a measured tone. I think such a tone  
is very important, since it contrasts with Shamos's often-mocking one.  
Here are my specific comments.
1. I would not say that the paper's "title itself is weak". It seems  
gratuitous and, anyway, the sentence that follow will help the reader  
conclude that all on her own.
2. Remove the brackets around "it's that they aren't independently  
verified [to be operating properly]". Brackets are really only for  
editorial comments.
3. There is a departure from measured tone is in section 4, where you  
say that "His math here is positively shameful". It is, but it would be  
better to say, "His math here does not represent reality," since you  
present good evidence of this very thing.
4. Remove the brackets around "[for software of medium or better...]",  
and remove "I suppose that" from the same sentence.
5. Your response to Shamos's item 6 is very good: trust no one.
6. Your comment on Shamos's section 3.5 should make it clearer that  
you're worried about a local trigger for a vendor-provided Trojan  
Horse.
7. In your argument about slot machines, please find room to note that  
Nevada has a pretty extensive scheme of gaming machine regulation  far  
more extensive than any regulatory schemes (that I know of) for voting  
systems. The Nevada Gaming Control Board actually inspects not only  
software, but hardware! http://leg.state.nv.us/NRS/NRS-463.html (NRS  
463.670). Of course they don't do a perfect job,  
http://www.americancasinoguide.com/Tips/Slots-Honest.shtml , but at  
least they attempt something. Why don't we do this for voting systems?
8. Other reviewers made some excellent points. The one about the nature  
of republics is particularly important, and should be included in a  
form that, while avoiding flaming, makes the point that Shamos does not  
consider an illegitimate presidency to be a serious issue.

_______________________________________________
OVC discuss mailing lists
Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Sat Apr 30 23:17:06 2005

This archive was generated by hypermail 2.1.8 : Sat Apr 30 2005 - 23:17:22 CDT