RE: Security issues beyond ballots

From: Popkin, Laird (WMG Corp) <"Popkin,>
Date: Wed Apr 14 2004 - 12:58:08 CDT

AFAIK, many states have a legal definition of 'randomization'. For example,
I've read that in CA they publish the lists of candidates in alphabetical
order, which each precinct starting with a candidate so that overall there's
no bias. (though you could argue that the candidate that is at the top in LA
has an advantage over the candidate that starts at the top in San Jose...).
So if the laws define randomization procedures that are imlementable on
paper, they probably prohibit dynamic randomization (and EVM2003 is fine as
is). Of course, with touchscreens being put in place, perhaps the laws could
be updated/generalized, though there are pretty good reasons to require the
_exact_ ballot to be used in each location to be certified, rather than a
scheme for generating ballots dynamically at the time of voting.

There's usually a procedure for how the wording for propositions is
generated, spelled out by law. In NY I believe it involves giving both a
proponent and an opponent of the proposition equal space in the voter's
guide, and so on.

It would be useful for debugging and in testing for fraud, and doesn't seem
like a loss of privacy to me, if the VES (vote entry station) logged every
user interaction as a sequence with only relative timestamps from the first
interaction in a voting session. That is, I'd know exactly what each voter
did, in which order, so I could replay the events exactly as the user
performed them in order to test for timing-based fraud, but wouldn't be able
to pin down what time of day any of it occurred so that I couldn't say which
voter did what. And in testing I could randomly vary the time between
voters, just as in real life.

And if we're really paranoid we could record the click stream on the paper
ballot (hidden by the privacy folder) so that if it came down to it, a user
could hold up a ballot and duplicate the click sequence manually, and verify
that the same printed ballot resulted.

About the openness of the code, someone pointed out to me the other day that
one reason that he liked OVC using Python is that it's an interpreted
language, with the interpreter's on the CD for verification, so there's no
way for there to be a mis-match between the source code and the binaries. In
a compiled language, there's a risk to be addressed that the binaries you're
running don't match the source code you've inspected. Admittedly the issue
still exists for the python interpreter, but that doesn't seem as dangerous.
:-) (this is where the security people jump in).

The explanation of why opens source matters is wonderful. We should put that
on the site quite prominently (i.e. not just in the FAQ).

- LP

-----Original Message-----
From: owner-voting-project@afterburner.sonic.net
[mailto:owner-voting-project@afterburner.sonic.net]On Behalf Of David
Mertz
Sent: Wednesday, April 14, 2004 1:30 PM
To: voting-project@lists.sonic.net
Subject: [voting-project] Security issues beyond ballots

David Jefferson raises a number of excellent issues of security
problems that are not directly addressed by paper ballots. I have a
few comments on them.

On Apr 14, 2004, at 12:03 PM, David Jefferson wrote:
> (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 ).

I continue to believe that an optimal approach to these issues is
production of a paper Guide to an election, made available before the
election. With such a guide in hand, any software misrepresentation of
choices is detectable to voters.

> (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.)

Currently, EVM2003 does not perform any randomization at all. Choices
are presented in a fixed order (and therefore, some particular choice
at top).

While I would not oppose randomization in principle or categorically
(and the code would be simple enough), there will be many legal and
practical constraints to using it. For example, some jurisdictions
require privileged placement of candidates running with parties that
have achieved certain threshold vote levels in prior elections (i.e.
usually Democrat/Republican in USA). Full randomization would be
prohibited in that case.

At a more practical level, randomization pulls against the usefulness
of an Election Guide. If the precise arrangement of a ballot GUI
cannot be predicted in advance, you cannot include a printed screenshot
of what a ballot is supposed to look like. Even short of a screenshot,
any ordered list of options will not necessarily match a ballot GUI. A
lot of voters might, in prior consideration, make a mental annotation
that they want to vote for the 2nd candidate in race 1, and the 3rd
candidate in race 2. Randomization breaks that (possibly leading to
votes not matching voter intent).

> (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!

This is practically the RULE for existing propositions. A huge number
of them seemed to be worded in a deliberately confusing manner.

But I agree there is an issue here. Even with a printed guide in hand,
voters are quite likely to overlook a subtle change in wording between
a printed pamphlet and a screen display--and possibly vote wrong as a
result.

> (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.

Some of the issues about order/timestamps being correlatable with
individual voters are covered in the "Ballot" section of Karl's FAQ
(that I contributed, but Karl gussied up). However, the issue there
was primarily in regard to printed records, not what is stored in
machine memory.

Amit's Security Wiki addresses some more general attacks, but it's
still in fairly simple outline. It might be time to start enhancing
that shared document:

        http://gnosis.python-hosting.com/cgi-bin/wiki.cgi?SecurityDiscussion

> 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!

Here I entirely agree. Open code doesn't guarantee the absence of
errors--or even attacks--but it's sure better than closed code in this
regard.

Also, Python makes it a WHOLE LOT harder to hide subtle errors than
does C or Java. Everything funny in Python pretty much LOOKS funny: if
code starts assigning to obj.__class__ or obj.__dict__ unexpected
things can happen; but the surface of the code tells you to pay extra
attention to such a danger. In fact, as a standard, we should pretty
much prohibit "funny" code in our Python source.

However, I find the openness of code to be a deeper requirement than
the "many eyes" security issue alone suggests. I wrote before about
why transparency is necessary for real democracy:

        http://gnosis.python-hosting.com/voting-project/April.2004/0072.html

I welcome comment on the phrasing, but I think something like this
needs to be in our public documents. It is important!

Yours, David...

---[ to our friends at TLAs (spread the word) ]-----------------------
Iran nuclear neocon POTUS patriot Pakistan weaponized uranium invasion
smallpox Gitmo Castro Tikrit armed revolution Carnivore al-Qaeda sarin
---[ Gnosis Software ("We know stuff") <mertz@gnosis.cx> ]-----------

==================================================================
= 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