Re: Left off the ballot?

From: charlie strauss <cems_at_earthlink_dot_net>
Date: Wed Apr 14 2004 - 12:10:40 CDT

Nice list. I'll add two more to it.

Inspite of voter verification one can assume that many machine-error-caused or malicious vote changes will pass through un-noticed.

Historically, this fact has been used for rigging. Punch cards can be "rigged" at the printing plant by filing down the dies that pre-perforate the chads, making the chads for one candidate slightly harder to dislodge than another. On lever machines, gears can be filled down leading to occasional vote skips or levers can be made sticky. And of course we all know about the confusing butterfly ballot layouts

The analogy to touch screens is the following

1) systematically misallign the touch-screen and image so, for example, democrat buttons are harder to actuate than republican, leading to missed votes. Examples of this occuring recently are in Maryland and Dallas Texas where virtually any press was recorded as republican. In Dallas, over 18 machines were found to have this misallingment--the total number that had it are not known. (suits were reportedly filed). Note I am not suggesting anything partisan or alleging this was anything but an mistake here by naming one party or another.

2) Systematically, making changing the votes say 2% of the time so that votes toggle to another candidate before the ballot is printed out. Sure the voter can verify on paper this happened but what fraction actually will. Even for those alert voters, for minor races and bond issues its often hard to recall the context of the race and what yes/no actually meant.

Thus open source is needed. Frankly I think open firmware (on the video cards, cd-roms, boot tracks) ought to be included.

-----Original Message-----
From: David Jefferson <>
Sent: Apr 14, 2004 10:03 AM
Cc: David Jefferson <>
Subject: Re: [voting-project] Left off the ballot?

May I propose a different angle on the "Left off the ballot problem".
For a while I have been making an informal mental list of the kinds of
code fraud that might occur that are fundamentally NOT addressable by
voter verified paper ballots. They include the following:

(1) Leaving candidate choices off of the ballot presented to the
voter--exactly the issue under discussion here.

(2) Leaving whole propositions off of the ballot (variation of (1)
above ).

(3) Improper randomization or rotation of the ballot, so as to put a
favored candidate at or near the top of the list much more often than
he or she is entitled to. (No voter, looking at only one ballot on
screen, can observe this statistical bias.)

(4) Modification of the wording of a proposition text to reverse its
sense, so that a voter in favor of the proposition when correctly
worded, will vote NO if he bases his vote on the wording presented on
the screen. Maybe this is done only on the Spanish ballots!

(5) Violation of privacy: a specific touch sequence on the screen might
present a list IN THE ORDER CAST of all of the votes cast on the
machine this day.

The point is that there are a lot of possible code frauds that are not
reasonably detectable by vote verification alone.

My suggestion is the OVC make this point publically and strongly: the
bottom line is that the only possible way to know that problems like
these are not written into the code is to make the code public!

I say this because those of us in the voter-verified paper trail
"movement" often speak and write as if vote verification is a silver
bullet preventing all software-based DRE fraud. Partly this is because
the more complex argument--that it prevents a huge amount of fraud--has
been enough to get traction without confusing the issue, and partly I
think it is because the many of us have not completely thought out all
of the ways that fraud might be written into DRE code.

Your message, therefore, is that even though it is not a panacea
either, there is absolutely no substitute for published code.

= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Fri Apr 30 23:17:06 2004

This archive was generated by hypermail 2.1.8 : Fri Apr 30 2004 - 23:17:29 CDT