Re: Shamos rebuttal -- re-visit

From: laird popkin <lairdp_at_gmail_dot_com>
Date: Fri Apr 15 2005 - 15:01:11 CDT

I am stunned at the high quality of this discussion.

We need to get the resulting document widely disseminated, and
legitimized for reference. Can we submit it for publication in a
relevant journal, and/or get a bunch of OVC supporters who are well
known in the voting world to publicly sign off on it?

- LP

On 4/14/05, Teresa Hommel <tahommel@earthlink.net> wrote:
> THIS IS SUCH GOOD MATERIAL!! I INSERTED SOME COMMENTS IN UPPERCASE.
> Teresa Hommel
>
> Ron Crane wrote:
>
> 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.
>
> ERRORS ARE NOT NECESSARILY CANDIDATE-NEUTRAL. AN ERROR COULD OMIT TO ADD
> ALL OR A PERCENTAGE OF VOTES FOR A GIVEN CANDIDATE OR PARTY.
>
> 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.
> ABSENTEE BALLOTS MAY NOT BE COUNTED AT ALL IF THE MARGIN OF VICTORY IS
> GREATER THAN THE NUMBER OF ABSENTEE BALLOTS.
>
>
> 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.
>
> NO DRE ELECTION OUTCOME HAS EVER BEEN INDEPENDENTLY VERIFIED
>
> 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.
>
> DON'T GET DRAWN INTO THE USELESS SUBJECT OF PROVING THE "SAFETY AND
> EFFECTIVENESS" OF VOTING SYSTEMS. ELECTIONS ARE NOT ABOUT VOTING SYSTEMS,
> THEY ARE ABOUT VOTES CAST ON BALLOTS, AND ALL ELECTIONS THAT DON'T ALLOW
> MEANINGFUL APPROPRIATE MULTI-PARTISAN NON-TECHNICAL OBSERVATION OF
> VOTE-CASTING (VOTER INSPECTS HIS/HER VVPB) AND VOTE-COUNTING (PEOPLE WATCH
> THE COUNT OF VOTES ON THE VVPBs) ARE INVITATIONS TO FRAUD BECAUSE NO ONE
> REALLY KNOWS WHAT THE COMPUTER DID.
>
> 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.]
>
> THERE'S A PILOT. NO ONE ENTRUSTS HIM OR HERSELF TO AIRPLANE SOFTWARE.
>
> 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.
> REQUIRE ALL VOTING MACHINES TO BE ACCOMPANIED BY A SUFFICIENT NUMBER OF
> EMERGENCY PAPER BALLOTS SO THAT IF THE MACHINE MALFUNCTIONS, IT IS TAKEN OUT
> OF SERVICE AND VOTERS USE PAPER BALLOTS.
>
>
> 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?
> PEOPLE'S BELIEF AS TO WHETHER OR NOT INDIA HAD A LEGITIMATE ELECTION USING
> ELECTRONIC VOTING SYSTEMS DEPENDS ENTIRELY ON WHAT NEWS YOU READ. ACCORDING
> TO SOME REPORTS IT WAS A DISASTER OF BROKEN SYSTEMS AND FRAUD.
>
>
> 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.
> I WOULD SAY THAT MOST VOTERS WOULD CERTAINLY CARE AND VERIFY IF THEY
> SUSPECTED THAT IT WAS NECESSARY.
>
>
> 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.
> AND ELECTION INSIDERS.
>
>
> 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.
>
> ELECTION-DAY STAFF CAN BARELY BOOT UP THEIR VOTING MACHINES. WHO EXACTLY IS
> GOING TO HANDLE THE PARALLEL TESTING -- THE VENDOR? REGARDLESS OF WHO
> PERFORMS THE PARALLEL TEST, HOW CAN NON-TECHNICAL MULTIPARTISAN CITIZEN
> ELECTION OBSERVERS EFFECTIVELY OBSERVE THE TEST TO CONFIRM THAT IT IS DONE
> CORRECTLY AND WHAT IT MEANS?
>
>
> 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
>
>
> _______________________________________________
> OVC discuss mailing lists
> Send requests to subscribe or unsubscribe to
> arthur@openvotingconsortium.org
>
>

-- 
- Laird Popkin, cell: 917/453-0700
_______________________________________________
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:07 2005

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