Re: Shamos rebuttal -- re-visit

From: Teresa Hommel <tahommel_at_earthlink_dot_net>
Date: Thu Apr 14 2005 - 17:59:19 CDT

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
==================================================================
= 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