RE: Security issues beyond ballots

From: Arnold Urken <aurken_at_stevens_dot_edu>
Date: Wed Apr 14 2004 - 12:40:12 CDT


The entire discussion on security is raising excellent points. It will
be a challenge for us to make use of patterns extracted from audit
trails to see what types of abuses we can prevent and/or detect.

Randomization is also a problem because parties vie for the top spot on
a ballot and will not want randomization at all. I know that in Essex
County NJ, the top spot is assigned based on a coin toss--one which has
turned up favorably for the Democrats for decades!

Our software should be able to deliver whatever users define as the
conditions for their elections.


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

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

> 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

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:

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") <> ]-----------

Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (
Version: 6.0.656 / Virus Database: 421 - Release Date: 4/9/2004
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
Version: 6.0.656 / Virus Database: 421 - Release Date: 4/9/2004
= 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