Re: draft of text for new OVC-sponsored bill

From: Jim Tobias <tobias_at_inclusive_dot_com>
Date: Tue Jan 20 2009 - 15:25:40 CST

Also please keep in mind that hand-marked ballots cannot be accessible to
people with disabilities; accessibility is required by law and common sense.
Even a large print ballot (unless it is used by all voters) will impose an
additional design and tabulation burden.
The number of people who cannot effectively and conveniently complete a
paper ballot by hand due to visual or dexterity impairments is well above 10
million, and that number is growing.

Jim Tobias
Inclusive Technologies
+1.908.907.2387 v/sms
skype jimtobias



From: Alan Dechert []
Sent: Tuesday, January 20, 2009 4:12 PM
To: Open Voting Consortium discussion list
Subject: Re: [OVC-discuss] draft of text for new OVC-sponsored bill

Ron, we've been around and around on this one for ages. Hand-counted
hand-marked paper ballots (HCPB) are simply not an option for the kind of
election system we have in the US -- especially in urban areas where 80
percent of the population lives.
You ought to review some of the discussion at on this.
transparent_election_systems&page=2> &page=2
I always challenge HCPB advocates to come up with numbers. Rarely do they
give numbers. Shiela Parks actually did give some reasonable estimates, as
far as she went. When you look at it more carefully, HCPB would be very
expensive in order to make it secure. According to her numbers, 100,000
people would be needed in Los Angeles to count ballots on election night.
Using volunteers for this is absolutely inconceivable. You'd have to hire
them. Think about all the infrastructure you have to have in place to do
all the hiring, screening, and coordination.
Even if you committed the resources to do this, it still has huge security
risks. After a few cycles, and gamers learn the system, how do you ensure
the people you are hiring are not part of some ring organized to steal votes
for their side?
HCPB advocates, including you, Ron, cannot be taken seriously until you have
a detailed plan for how you are going to conduct elections in urban areas
with 40 - 50 contests on a ballot -- sometimes over 100 candidates appearing
on a single ballot. All I ever get are hand-waves -- like we do this all
the time, organizing huge numbers of people. Sure, the military does this,
but the military has a $500 billion budget.
Even if you can budget for all the hiring and screening and overhead, hand
marked ballots have voter intent problems.
The problem with HCPB advocacy is always the same: they point to where HCPB
has been used successfully. Unfortunately, the examples they always use are
irrelevant (like countries where they have one thing or a very few things on
the ballot). The real history of HCPB is rife with political machinery that
takes over the counting and rigs the elections. Read about Tammany Hall and
many other examples. You need people to show up and count ballots? Sure,
they'll send you some people.
There were quite a few HCPB advocates that started threads on
None of them were able to get more than about 100 votes. If 100,000 people
were showing up to vote for HCPB, I might actually think you could get some
volunteers. But you can't. There are very very few people willing to show
up for it -- especially in urban areas where people are very busy and used
to using technology to get things done.
Secure HCPB -- in urban US -- is a pure fantasy.

----- Original Message -----
From: Ronald <> Crane
To: Open Voting Consortium <>
discussion list
Sent: Tuesday, January 20, 2009 12:23 PM
Subject: Re: [OVC-discuss] draft of text for new OVC-sponsored bill

Probably everyone but Diebold, et al, agrees that open-source computational
voting systems are likely to be more secure than closed-source computational
voting systems. But are they safer than hand-filled paper ballot systems? I
don't think so, because of the attacks I mentioned, and other attacks (e.g.,
on "voter verification").

I think that we should use computational ballot presentation and recording
devices only to assist disabled voters to vote independently. I believe that
their advantages (e.g., definiteness of ballot markings and
overvote/undervote checking) are heavily outweighed by their security risks
when used by the general voting population.


laird popkin wrote:

Keep in mind that security isn't an absolute, but is a matter of

presenting sufficient costs and risks around an attack that the attack

is deterred.

So, while in an absolute sense any software system has the same issue

(you cannot 100% prove that all of the machines are running the

correct software), open software is (IMO) significantly more open to

validation because every step in the process can be open to

inspection, while a proprietary voting system relies on hiding the

code to protect the vendor's IP.

For example, you can validate that the software is correct by

independently compiling your own copy and comparing the binaries,

proving that the vendor's compiler didn't sneak code in, and that the

source wasn't modified. You could distribute the executable and data

files on CD's, with witnesses validating the duplication,

distribution, etc., and boot the PC's from CD to run the election.

Given such an approach there are still possible attacks, such as BIOS

hacking, or threatening to shoot voters unless you can watch them vote

"properly", but in terms of the specific issue of software validation,

open source software is (IMO) certainly safer than running a vendor

loading modified software in "black box" voting machines. :-)

- LP

On Tue, Jan 20, 2009 at 2:51 PM, Ronald Crane <>
<> wrote:


cls wrote:


I'm especially alarmed at sweeping that nagging image verification

problem under the rug. It's the Achilles Heel of this whole approach.

Nobody has yet described to me how I can convince an electronic voting

skeptic that the image he just voted on was built from the exact sources

his expert inspected on the Registrar's web site last week.

Ja, not to mention firmware-based attacks that instrument the image, so that

an attacker can cheat even if we somehow verify that the correct image has

been loaded into every machine.

I'm leaning towards admitting it's intractible during the time frame

of interest, and insisting on a design that *doesn't care* about

any particular software installation. Open source is important, but

not for solving this particular security problem. I want a solution

that can blow the doors off the hand-marked, hand-counted, no-computers-

in-the-whole-chain luddite bandwagon. I can't do that if my solution

depends on being able to verify and authenticate CD images.

The cryptographic strength and verifiability of those paper ballots,

(and the simplicity and verifiability of their custody protocol)

has to do it alone.

Crypto (or "end-to-end" (E2E)) voting systems are still vulnerable to a

variety of attacks, particularly if they use a computational device to

present the ballot or to collect the voter's selections. There are at least

three kinds of attacks:

1. DoS. The machines selectively can impede, delay, or prevent voters from

voting. This attack can range from the heavy-handed (e.g., repeatedly

crashing and rebooting; locking up) to the subtle (e.g., making voting take

longer by making the GUI laggy, or by lengthening the time to reinitialize

for a new voter). Or, officials can simply cheat by manipulating machine

allocations, as seems to have happened in Ohio's 2004 Presidential race. .

2. Presentation attack. The machines can selectively omit candidates from

the ballot, reorder it, change the race headings to de-emphasize certain

races, or make it easier or more difficult to select certain candidates.

This attack could be very effective; in 2006, there was a massive (13%)

undervote in Florida CD 13 (Sarasota), which quite possibly flipped the

result. Officials attributed it to incorrect race headings.

. There's no reason that a presentation attack on race headings couldn't

produce a similar effect.

3. Social engineering attack on E2E protocol. E2E can provide strong

security guarantees, but they're valid only if the user and machine follow

the correct protocol. An attacker can program the machine to guide the user

to perform an incorrect protocol, thus voiding the guarantees. Since E2E

protocols (e.g., VHTI) are unintuitive, most voters won't realize that

something has gone wrong. And even if a voter notices a problem, officials

are almost certain to attribute it to "voter error" or "a glitch".

That said, it's still possible to wage these attacks on hand-filled paper

ballot systems, including ones that use E2E (e.g., ThreeBallot), but it's

more difficult. A DoS attack is obvious (Where are the ballots?), while

presentation attacks can be caught by randomly auditing the ballots. It's

not quite so clear that ballot audits could catch social engineering attacks

on E2E, though correct instruction posters in the polling place could help a


Computers are wonderfully powerful tools, but they are not necessarily

suitable for every purpose.



OVC-discuss mailing list

By sending email to the OVC-discuss list, you thereby agree to release the

content of your posts to the Public Domain--with the exception of

copyrighted material quoted according to fair use, including publicly

archiving at




OVC-discuss mailing list
By sending email to the OVC-discuss list, you thereby agree to release the
content of your posts to the Public Domain--with the exception of
copyrighted material quoted according to fair use, including publicly
archiving at

OVC-discuss mailing list
By sending email to the OVC-discuss list, you thereby agree to release the content of your posts to the Public Domain--with the exception of copyrighted material quoted according to fair use, including publicly archiving at

= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Thu Jan 7 00:09:47 2010

This archive was generated by hypermail 2.1.8 : Thu Jan 07 2010 - 00:09:57 CST