RE: Spoiled ballots, forged ballots, destroyed ballots

From: John Payson <jpayson_at_circad_dot_com>
Date: Fri Jun 11 2004 - 21:41:12 CDT

On Jun 11, 2004, at 8:14 PM, John Payson wrote:
> Apoligies for my incorrect terminology. What I meant was a ballot
> which has been altered in such a way as to be no longer valid, but
> which still exists.
>>
I'm not sure what such an alteration could be. A damaged ballot isn't
really *invalid*, even if it is *unreadable*. It's our obligation to
extract the voters intent from whatever we have available, as long as
we believe it reflects a genuine expression of voting preference
(rather than a forged ballots... obviously we're limited by physics and
technology in our obligation).
<<

Election rules almost everywhere require that a ballot which contains any marks
by the voter other than those which are required to make the indicated votes is
invalid. There was actually an election in Rockford, IL, which rested on the
fact that some voters had either filled in or put a check mark in a box, rather
than putting an "X" in it as directed. The voters' intentions were not
ambiguous, but the ballots were nonetheless considered void.

>>
The main aspect of trust in OVC's design (or, I believe, in ANY design)
isn't really in computers, but in procedural safeguards.
Chain-of-custody, contesting parties as monitors, etc. If you imagine
a big enough conspiracy, you can well imagine the entire election was a
mockup in which all real votes are discarded... and fake ones
substituted (even to match some home-run software).
<<

Protecting ballots against outright substitution is a somewhat-tricky
issue--indeed, it's the one attack which my protocol can't very well protect
against (although if ballots are initially tabulated at the polling site, there
would be some cause for suspicion if the ballots later show different votes).

Other than that, though, the fundamental problem is one of demonstrating to an
interested and knowledgeable person that if the election equipment recorded
votes inaccurately, it would most likely get discovered (and therefore if such
inaccuracy is not discovered, it's probably accurate). So far as I can tell,
the only way of doing this is to ensure that any inaccurate record by the
voting equipment has a certain likelihood of being detected.

>>
For example, the "claim" that voting stations run the same software
alleged (and released to the public) is mostly a matter of rules for
handling the distributed CDs, computer, etc. Sure, we'll use
cryptographic signatures and all... but we trust voting officials to
run the signature checks and not lie about the results. Of course, we
trust voting officials partially on the condition that they have a
Democrat standing over their left shoulder and a Republican standing
over their right shoulder while they perform the checks. But still,
most of the trust is in PEOPLE not in BITS.
<<

Well, in Chicago they'll have Democrats looking over both shoulders, with nary
a Republican in sight. Of course, that allows for all sort of other
shenanigans far beyond voting-machine hijinx. But members of both parties
follow the parts of each machine from the semiconductor plant all the way to
the voting booth, there's no way to really be sure the machines are legit.
While some of the more interesting hacks would require someone to have a decent
bankroll (e.g. producing custom LSI chips which would mostly emulate "real"
ones but would, when certain sequences of instructions were executed, behave
"interestingly") I don't think they'd be beyond the reach of many foreign
governments.

It's possible to design a protocol that doesn't require anyone to trust any
computers other than their own at all. While the more interesting hacks would
be difficult even without such protocols, making them impossible would seem
even better.
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Wed Jun 30 23:17:13 2004

This archive was generated by hypermail 2.1.8 : Wed Jun 30 2004 - 23:17:30 CDT