Subject: Re: internet voting -- ICANN, SmartInitiatives, etc.

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 15 Jan 2001 01:37:48 -0500

In message <[email-masked]>, Ed Gerck writes:

>Handling bugs is the major problem IMO (looks like we also agree here)
>after DDoS, privacy, security, integrity, etc are handled (which are
>not a small task, either).  But this might not be so hard after all.  Yes,
>an election is a mission-critical application but it is also a fixed application
>if you design it well with a database paradigm. The database changes
>for every election (candidates, offices, etc.) but the software is the same
>at each different stations (registration, voting, ballot box, tallying,
>reporting, auditing, etc.).

Of course, the software isn't fixed, any more than any other package is 
fixed.  If nothing else, each election will have software that includes 
the bug fixes and new features added since the last election.

The real model for electronic voting isn't Florida, though; it's New 
Mexico.  In Bernalillo County, which used optical mark ballots, the 
scanner was misprogrammed -- it ignored straight-ticket votes.  In this 
case, once the problem was recognized, the fix was relatively easy -- 
they corrected the program and rescanned the ballots.  If the voting had 
been online, there would have been no physical ballots to rescan.

>And, elections already use software -- even if you just use punch cards.
>So, this is NOT a new problem either.  In fact, it is worse today because
>it all closed source software (in the good name of security).
>

Believe me, that software scares me, too...  And open source, though a 
help, is hardly a panacea; finding bugs is *hard*, and testing is not 
at all adequate.

		--Steve Bellovin, http:/www.research.att.com/~smb

---

From: Ed Gerck <[email-masked]>
Date: Sun, 14 Jan 2001 22:58:30 -0800

> the bug fixes and new features added since the last election.

Yes in a small part.  Elections cannot have added features so easily because
the election machines must be state certified (a lengthy and costly
procedure) and the ballots must comply to current laws (Palm Beach being
the exception that justifies the rule).  So, a "vote for one" race or "vote for
three" is pretty much the same for almost 100 years now in terms of features
and ballot lay-out. And election officials prefer it so -- their mantra (and
a good one in this case but not if taken too much to the letter) is "if it
ain't broken don't fix it".

The only thing that should change is the bug fixes, which should also
taper off after a while since there should be no new features driving new
bugs.

> been online, there would have been no physical ballots to rescan.

Not true, not even with current minimum FEC standards.  And note that
the draft for future FEC standards for online voting defines online voting as
a branch of electronic voting.

The point is that what was wrong in New Mexico as you report was the
tallying and this could be redone by re-running the ballot images mandated
by the FEC to be stored in the ballot box part of each electronic voting machine.
If this same requirement is kept for online voting, then remote ballot boxes
would hold copies of all ballots and they could be re-tallied with the bug fixed.
Once the same type problem is recognized, the fix is even easier since there are no
ballots to be rescanned, just re-tallied.

Cheers,

Ed Gerck

---

From: Daniel Senie <[email-masked]>
Date: Mon, 15 Jan 2001 09:00:14 -0500

> been online, there would have been no physical ballots to rescan.

In 1982 a team of 4 students at Rensselaer Polytech. created a secure
voting system. I was one of that team. We had many concerns to overcome,
none the least of which was how to separate the vote gathering from the
vote tallying. We separated out these functions precisely becase we were
concerned about being able to hand-count the votes later. This system
wasn't an academic exercise. Rather, it was driven by a desire to
demonstrate the ability to apply technology to the campus elections. It
worked well. Security was maintained by using physically separate
terminals and relying on aspects of the operating system. We're talking
3270-style terminals and an IBM mainframe, for those curious. The
terminals can be programmed such that all control comes from the host,
making them ideal for the task.

In our case, we stored each vote separately in a data file, effectively
keeping each person's ballot together. We designed the system to write
the files to multiple disk drives simultaneously, so we could compare
the data later (and protect against a drive failure).

This issue of having ballots available to look at later is important. In
the town where I now live, we use traditional paper ballots. I expect
it'd be a VERY difficult fight to move from them to ANYTHING automated.
And despite having written an early voting system, I still prefer voting
on paper.

> help, is hardly a panacea; finding bugs is *hard*, and testing is not

I echo Steve's sentiments here. With the system I worked on 19 years
ago, we found bugs in the counting program once we had the final dataset
(i.e. after the vote), and had to make some adjustments there. Election
officials were in the room watching as we recoded a bit, got access to a
newer compiler that didn't have as many bugs in it, and eventually got
the results generated. The software continued to be used for quite a few
years after that, and each year it'd get tweaked to fix problems,
accomodate new ballots, and so forth.

Security programming, encryption and transmission are far from the only
areas where problems will exist. Election software isn't run often, and
it's updated as needed for each election. The disk files we stored had
the names of the candidates receiving votes in text, not in binary. As a
result, if it'd been necessary, the votes could have been hand-tallied.
I doubt I'll be dissuaded from a firm belief in the need for
human-readable ballots which can be counted and recounted manually.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com