Re: Shamos rebuttal -- re-visit

From: Ron Crane <voting_at_lastland_dot_net>
Date: Sat Apr 16 2005 - 13:55:50 CDT

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