Re: Shamos rebuttal -- re-visit

From: Arthur Keller <voting_at_kellers_dot_org>
Date: Fri Apr 15 2005 - 15:12:59 CDT

I think that's an excellent suggestion. Perhaps the next step is to
circulate a comprehensive version that combines the various comments.
We'll need to provide appropriate footnotes and references. In the
next pass, please include the references to the Shamos article for
cross-checking. Thanks.

Best regards,
Arthur

At 4:01 PM -0400 4/15/05, 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

-- 
-------------------------------------------------------------------------------
Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA  94303-4507
tel +1(650)424-0202, fax +1(650)424-0424
_______________________________________________
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