Re: A generic best practice document for New Mexico legislators

From: Charlie Strauss <cems_at_earthlink_dot_net>
Date: Mon Dec 27 2004 - 00:08:53 CST

On Dec 26, 2004, at 8:10 PM, Teresa Hommel wrote:
> There is an unspoken argument here.  It is that elections CANNOT be
> held to ordinary, routine IT standards. This idea is based on the
> unspoken acknowledgement that Boards of Election in real life cannot
> perform such audits. They lack not only the intention or will, but the
> legal mandate, expertise, staff, and funding.

Right, this is the key issue. So what should we do?
should we try for orthodoxy and possibly create a prohibitively complex
I'd value your feedback on this issue. It's a tough one.

> Problems with surprise random recounts of small percentages of
> ballots.
> 1. Trust-the-statistician vs. observation. If observers can watch a
> count of 1% of the ballots cast, then your election has 1% legitimacy.
> Discussions about "statistically significant percentages" leave
> ordinary non-technical election observers in the dust. No one should
> be forced to trust some statisticians that some percentage of ballots
> is statistically significant.  Most of us would rather trust Albert
> Einstein than a vendor technician, but why intentionally set up a
> "trust someone" situation in an election. The only appropriate people
> to trust are your local bipartisan or multipartisan election
> observers, who are ordinary citizens.

As long as there is a barcode or some machine countable tag on the
paper ballot then it's not prohibitive to count all the paper ballots
accurately. If not then the next best thing is to count 1% (or some
fraction). When counting purely by hand and eye one has a lot of
question on the ballot to record and accuracy is going to be a problem.
  Thus I was suggesting a minumum feasible amount to do.

> 3. Certain types of computer errors and fraud may not show up in
> small recounts. These include intermittent errors or fraud triggered
> by particular combinations of votes and/or particular ballot designs,
> and legally "insignificant" vote switches per machine. The recent Yale
> Study showed that with a single statewide system, centralized
> manipulation is facilitated and can swing elections with one or two
> vote switches per machine. The study and commentary are online.
>    Commentary on Yale Study   
>    Yale Study

I dont see how this relates. If you are recounting 1% of the votes at
random these are exactly the sorts of errors would be picked up with
high likelihood.

While you don't want to trust statistics to assure election integrity,
you are anyhow. That is to say, at some level of likelihood there
exists the possibility that both the electronic records and paper
record were both rigged. There's no reason to force some other part of
the election process to have a statistical assurance below that level.

> 4. Creation of two classes of voters. 1% of voters would cast ballots
> that were confirmed to be tallied correctly. 99% of voters would cast
> ballots that were not.

This is a weak argument from a statistical point of view. And for that
matter you are creating new desiderata here that did not exist
previously: Currently all recounts are selective. it would be rare for
any recount to recount all races on a ballot. so those non-recounted
races are not equally protected.

> 5. The requirement for small surprise random recounts mandates
> unverified elections, or else puts the responsibility on candidates,
> voters, and political parties to pay for recounts, or struggle in the
> courts for the right to verify an election. Honest elections have to
> start out with observable procedures.
> 6. Electronic voting and vote tabulating systems are being treated as
> an exception to professional IT standards. In my work with computers
> since 1967, every computer system that I have encountered in
> professional use is 100% audited, and discrepancies are reconciled for
> 100% accuracy.


> It may be useful to compare the security that we imagine is needed
> for elections and banking.
> Suppose you find an error on your bank statement, and you go in with
> your records, and the bank officer says, "we didn't audit your account
> this month, because our statistically significant random check said we
> were accurate enough." That is ridiculous.

Spot checks are standard practice. The IRS certainly works this way.
Its common in industry to have selective inventories. At the
government lab where I work we are routinely given a randomly selected
list of items from our property records and told to find them. If you
dont then you have a wall to wall inventory. So if you found and error
on your bank statement then you would need to check.

> People understand that 100% audits with 100% accuracy are needed to
> prevent or detect financial fraud, but don't carry this idea over into
> the world of elections.

> Elections are not a court of law where a piece of technology is
> assumed accurate until proven inaccurate. When people insist on
> starting out with the premise that computers are accurate until proven
> otherwise, we are seeing something very wrong, and dangerous for
> democracy.
> Teresa Hommel
> Edmund R. Kennedy wrote:
> Hello Charley:
> Voting software needs to be available a fixed time before the
> election, say 8-12 weeks.  Otherwise, the vendor could release it the
> day before the election and still be in compliance.  Is 'ballot
> secrecy' a phrase of the art?  I would be more inclined to talk about
> voter privacy or the secrecy of the voter's ballot.
> Thanks, Ed Kennedy
> charlie strauss <> wrote:
> I am trying to formulate a best practices document for New Mexico's
> legislators. This is intended as a terse summary of mandatory items to
> consider in legislation with specific reccomendations. It is not
> supposed to be a discussion of issues, tradeoffs or considerations.
> It's also intended to be vendor neutral and not to overtly prohibit
> any reasonable vendor. It's not an advertising brochure for OVC. It is
> a foot in the door and was in fact solicited by govenment officials.
> We hope to provide a broader discussion document later.
> If you have your own best practices documents or links to ones you
> like or links to effective legislation please send those to me or post
> them as a reply.
> comments are extremely welcome.
> (NOTE: The omission of Alan Dechert or others tied directly to OVC
> implementation from the list of experts is not a slight but was
> deliberate ! for the same and obvious reason that I also omitted the
> CEO of Avante and certain other highly skilled people.)
> Electronic Voting System Best Practices Document
> Verified Voting New Mexico
> Point of Contact: Charlie Strauss
> Basic principles for trustable elections
> 1) It is not enough that elections be accurate, they have to provably
> so and in manner transparent to voters.
> 2) Errors will occur. We must design systems that can recover from
> errors, not design systems that require unachievable levels of
> perfection in hardware, software, and operators.
> 3) Innocent anomalies will occur. Without open systems, errors,
> fraud, and innocent anomalies can appear indistinguishable; for
> elections to be trustable we have to be confident we can distinguish
> these.
> To strike an analogy: open meetings laws not only prevent
> conspiracies they also lead to public trust in governance without all
> parties having to have blind faith. In any! given meeting, the
> oversight imposed by meetings-laws may seem inconvenient or onerous,
> but in hindsight it cumulatively leads to a more efficient government
> because it is trusted.
> Get expert advice
> We recommend forming a panel of experts to guide voting system
> requirements. In particular we can recommend Prof. Avi Ruben (Johns
> Hopkins), Prof. Doug Jones (Iowa State), Dr. David Jefferson (Lawrence
> Livermore National Lab), Dr. Rebecca Mercuri, Dr. David Mertz and Prof
> David Dill (Stanford). Dr. Jefferson has been instrumental in guiding
> the creation of California’s new standards. Prof. Ruben researches
> modern voting system security. Prof. Jones has published numerous
> papers on the subject and critically analyzed touchscreen software
> errors in Florida. Mertz, Jones and Mercuri have separately laid out
> design precepts for secure, trustable voting systems with voter
> verified paper trails.
> The new draft California standards and laws will be a useful
> reference for New ! Mexico. Harvard University recently published an
> election systems best-practices guide that also addresses these
> issues. If you cannot obtain these directly we can assist you in
> getting pre-prints.
> We recommend against two advisors preferred by the outgoing Election
> Director, Denise lamb: many positions advocated by Prof. Ted Selker
> and Prof. Michael Ian Shamos are widely disputed by their peers in the
> computer science community.
> Twelve essential requirements for trustable electronic voting
> 1) The voting system shall produce a paper ballot, inspectable by the
> voter at the time of voting, and secured at the polling place. The
> voter may spoil the ballot and re-vote if not satisfied the ballot is
> correct. Spoiled ballots should be retained at the poll, or their
> absence explained by polling officials (similar to the method used
> now).
> 2) Voting software must be freely inspectable by the public in both
> source code and binary format, without any non-disclosure ag!
> reements. By voting software we mean all components: configuration
> files, application, operating system, peripheral drivers, font files,
> and all firmware including video subsystems.
> 3) The Bureau of Elections shall conduct mandatory surprise recounts
> of the voter- verified records of each election in 1 percent of the
> jurisdictions immediately following each election. Half should be
> selected after the elections on a random basis. Half should be from
> nominations by the candidates. The Bureau shall promptly publish the
> results of those recounts.
> 4) If a bar-code is used in place of a text scanner or human to count
> the paper ballots, then 0.5% of these should be hand counted and
> compared in detail to the bar codes. Additionally, a bar code reader
> accessible to voters shall be available in every polling place so that
> voters may verify their own bar codes. All discrepancies will be
> published before canvassing.
> 5) In the event of a discrepancy between any electronic re! cord and
> the paper record, neither has primacy: a judge informed by experts
> will decide how to reconcile the difference on the basis of which is
> most likely to be correct under the specific circumstances in each
> case. A general policy mandating one form shall not be established,
> and election officials will not make the decision.
> 6) Vote storage formats, electronic and paper, shall either be
> non-proprietary or licensed under fixed and reasonable terms so that
> alternative vendors can produce compatible voting software and
> machinery.
> 7) Ballot secrecy must be preserved. Thus extreme administrative
> precautions must be taken if roll-tape or time-stamped, or
> serial-numbered ballots are employed since these preserve vote order.
> Similarly, electronic records that would enable reverse engineering
> vote order must be avoided or admistratively secured. Notably, if
> ballots reveal the voter’s preferred language some precautions should
> be used to preserve ballot secrecy, since rare l! anguages may
> indicate ethnicity or identity.
> 10) Absolutely no voter receipts — vote confirmation records taken
> home by a voter — shall be produced including “secure” cryptographic
> records.
> 11) Absolutely no remote communications or networking of machines.
> All data ports on the machine must be physically secured with tamper
> evident seals. Exposed data cables should be armored
> 12) All vote and audit records as well as all ballot configuration
> files should include standard good-practices such as checksums and
> digital signatures so that every file can be validated by any software
> reading it. Notably this includes all vote processing software not
> just the voting terminal software.
> Fourteen additional recommended best-practices
> 1) Legislation should distinguish between ballot marking devices,
> ballot storage systems, ballot readers, ballot counters, and Ballot
> databases. At present these separate functions are somewhat conflated
> in NM laws.
> 2) All! machine audit logs should be written to non-volatile,
> write-once media, signed by witnesses and physically secured in the
> machine with tamper evident seals. An example of this would be a paper
> tape or a write-once CD-r. Audit logs shall be published promptly.
> 3) To hold an election when a known bug exists, the SOS must identify
> the risk and certify countermeasures and each clerk must certify that
> the countermeasures are in place. All bugs, countermeasures and
> certification shall be published before an election is canvassed.
> 4) All software and operating systems should follow software design
> best practices, and notably all data records should be read into
> memory using a no-execute protocol available on modern CPUs, and any
> writable storage devices should be mounted using no-execute protocols.
> (In the event of a software error, no-execute protocols prevent
> accidental execution of portions of memory meant to store data and not
> programs.)
> 5) To allow a machine to secur! ely self-witness it’s own data:
> before any electronic vote storage devices are removed from a machine
> or the any device is connected to the machine after an election, the
> machine itself should write the vote records to a write-once
> non-volatile medium (CD-R) that was signed in advance by the election
> judges or other witnesses.
> 6) All software used by the machine should be loaded into the machine
> memory from non-writable media physically secured inside the machine
> and not accessible to any poll worker. This could include CD-roms or
> could include hard disks or flash memory whose write-functions have
> been physically disabled. The media should be encased in tamper
> evident seals and all randomly audited machines should have the
> software-containing device audited to insure that the binary software
> matches the certified software.
> 7) The voting machine should produce an audible ding (or flashing
> lamp) audible (or visible) to both the voter and election officials
> whenever! a valid paper ballot is produced. If a voter walks away
> without producing a ding or otherwise not depositing a ballot election
> officials should try to inform them a ballot has not been cast. The
> ding also inhibits voters with multiple stolen terminal activation
> cards from voting multiple times unobserved.
> 8) Parallel testing. At random on Election Day itself machines will
> be selected and pulled from operation. Teams of testers will vote on
> the machines under conditions simulating election conditions and
> patterns (including environmental factors). These should be video
> taped and the intended votes compared to the recoded votes with any
> discrepancies reconciled with the video.
> 9) In a similar vein the computer should have no means of estimating
> the true date beyond what is entered by a user via a single portal.
> Examples of hidden alternate time keeping include, battery drain, IR
> light sensors, AC wall voltage, and the clocks onboard peripheral
> devices such as the graphi! cs card or power management units.
> 10) Screen calibration validation periodically throughout Election
> Day. Anomalies logged
> 11) Line voltage logging on Election Day.
> 12) Cameras, particularly the voter’s own camera, are not permitted
> in the voting booth. This prevents spying, intimidation and
> vote-selling.
> 13) Sufficient voting machines to deal with 100% turnout and
> reasonable failure rates should be available.
> 14) Policies for abnormal conditions such as printer malfunction or
> machine malfunction should be established and published by the SOS
> prior to elections.
> Future issues
> In the future we anticipate the development of a hardware technology
> known as a “trusted computing platform” to emerge. This technology
> will allow a computer to self-validate it’s own software and hardware
> have not been tampered with and greatly enhance security. At present
> this technology is NOT available. However legislation should be
> designed foster migration of! this technology when it becomes
> available. Legislation can be designed now to anticipate securing the
> new key hardware devices that enable this platform.
> _______________________________________________
> OVC discuss mailing lists
> Send requests to subscribe or unsubscribe to
> --
> 10777 Bendigo Cove
> San Diego, CA 92126-2510
> "We must all cultivate our gardens." Candide-Voltaire
> _______________________________________________
> OVC discuss mailing lists
> Send requests to subscribe or unsubscribe to
> _______________________________________________
> OVC discuss mailing lists
> Send requests to subscribe or unsubscribe to

OVC discuss mailing lists
Send requests to subscribe or unsubscribe to
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Fri Dec 31 23:17:20 2004

This archive was generated by hypermail 2.1.8 : Fri Dec 31 2004 - 23:17:22 CST