Re: Shamos rebuttal -- re-visit

From: Alan Dechert <dechert_at_gmail_dot_com>
Date: Sat Apr 16 2005 - 15:18:18 CDT

Sorry, Ron, that I haven't been as responsive as you'd like in this
thread. I get that way when I need money. Our current fundraising
drive (ends Tues eve.) is off to a slow start. We're going to be
hard-pressed to meet our goal (which we must do). BTW, people on the
OVC-discuss list have contributed in the past and I need to ask to for
renewed support. I expect to spend significant time in the next few
days making fundraising calls, so I don't have a lot of time to spend
on this right now.

Anyway, if you want to make this into a nice paper and get
endorsements and such, I would be glad to have you as first author,
and list others that have contributed like we have done in the past
with other papers.

Alan D.

On 4/16/05, Ron Crane <voting@lastland.net> wrote:
> Thanks! Those are good suggestions and could really help us make our
> case. But first we need to hammer this proto-paper into shape. My
> Shamos rebuttal contains a few requests for help (items 7, 16, and
> especially 18) with areas that others here have more knowledge of, and
> experience in, than I do. Please see whether you can help. Also please
> review the entire rebuttal and post your comments here. Alan: I need
> your feedback especially.
>
> To make this a really good paper, it probably should be framed not so
> much as a rebuttal to Shamos, but as a rebuttal to common
> misconceptions about e-voting systems that happens to use Shamos's
> paper as the primary source of misconceptions.
>
> Comments? Flames? Or have a multitude of cats stolen most list
> participants' tongues?
>
> -Ron
>
> On Apr 15, 2005, at 1:01 PM, laird popkin wrote:
>
> > 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
> >
>
>
> _______________________________________________
> 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:08 2005

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