[Tfug] OK, got a different tech challenge on FOSS voting...

[Jim March]

OK, to understand better what we're dealing with, here's my comments today
to the project manager regarding this LiveCD boot disk/voting machine
"kiosk" software.  I'd like to keep this purely on TFug for now, OK?

Background for TFUG: the way this thing works is, it prints a paper ballot
containing both plain-English vote choices plus a barcode showing which
voting machine it came from.  It also stores an electronic copy of each
ballot image based on the voter's choices.  In this fashion it's both a
"ballot marking device" producing a paper record, and an "electronic voting
machine".  IF done right, this is actually cool: the electronic and paper
records act as a check against each other.  If they disagree, you KNOW
something bad happened.  A hacker therefore has to break both...unless of
course they can rig the output in the first place.  But the voter gets to
actually hold and look at the paper before putting it in a standard ballot
box, so that seems at least risky.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Having gone through the CD, I have some input for you.  Sorry this is so
late but I did some checking today.  You tend to be a late-owl so I'll call
you in a bit.

The good news:

1) The user interface for the voter is surprisingly good.

2) The basic concepts are sound.

3) Using a re-mixed Ubuntu LiveCD is a good idea.

File under "needs work":

4)  There needs to be some general cleanup; nothing too crazy, basically
have it start up to a front-end for the pollworkers consisting of:

a) Do the pre-election zero report.

b) Start the election.

c) Stop the election (once a special control printout is scanned, or
something).  This would include doing end-of-day reports.

5) Security needs work.  The easiest would be to rig Ubuntu such that it has
no ability to read from USB media, no ability to do Ethernet, etc.  That way
you don't need to tweak the hardware, glue the Ethernet port shut, etc.

6) The Python code needs to get compiled.  Python is by default interpreted
but full-on compilers exist.  No big deal and would save a bit of real
estate on the CD.  (However, the process of stripping "extra crap" off the
boot CD isn't done yet so CD real estate shouldn't get to a crisis point...)

The biggest issue however...

7) There needs to be a way to create a non-modifiable electronic record that
has ALL of the following characteristics:

a) Doesn't store the ballot images in sequential order tied to the vote.

b) Allows proving which paper ballots were created by that machine.

c) Stores them to non-volatile media of some sort.  This latter means we
need to think about hardware:

You're going to need two CD drives - only one (the second) need be a
burner.  If you're specifying custom hardware, make the boot a DVD-ROM so
that you have room to grow the code base, but otherwise dual CDs is fine.
Both should be on the IDE/ATAPI bus rather than one being external USB; in
order to use an external USB burner drive you'd have to enable USB media in
general I think?  Not kosher.  (IF I'm wrong about that, and come to think,
I might be, then we have the option of using touchscreen laptops which in
turn would solve the battery backup situation.  Let me check on that
point...)

If you specify at least 1.5gigs memory, you'll have enough RAM to hold the
whole day's ballot images and then burn them to disk as part of the
end-of-day process.  Just prior to that burn you can randomize the filenames
and timestamps of the image files to screw up the sequence.

8) BUT you have a problem: what happens if the power kills or the machine
crashes in mid-day?

I've been racking my brains for days on that one.  There are several
solutions but all have issues.

a) Use a USB memory stick to hold the ballot images plus a continuous
"counter" of how many voters have gone through, whether or not it's been
authorized, etc.  If you have to reboot off the LiveCD, it can read the USB
drive to see where the hell it was at when it crashed.  I do NOT like this
answer: it means we have to open it up to inserted media, and somebody could
shut it down, pull the stick, alter the stick, bring it back up, it thinks
it's in a new state.  Not cool.  Might be solvable with encryption but shit
gets complicated...

b) Use an internal hard disk that gets formatted in the "start things up"
process at the beginning of the day, holds the "continuous status" stuff
(and ballot images) same as the USB memory stick.  The good news is that
this is a third record available later in addition to the paper and the CD
you'd still burn.  The bad news: mid-day hardware hacking would still be
possible.

c) Go to multi-session recording on the CD burner.  Burn your stuff
throughout the day, doing a final-track write only at end of day.  This
could preserve the sequential order of votes again (a no-no as that could
break voter privacy).

d) Use CD-RW media on the burner drive, throughout the day save "snapshots"
of progress after each voter is done, erasing the previous snapshot.  Good
news is that each snapshot can have scrambled ballot image
filename/timestamp data.  Bad news: the media is eraseable and you've raised
end-of-day costs a tad - the "extra" disks you can burn for
observers/parties/candidates now cost $1.75 a pop versus 50 cents (with
case).

e) "Exotic hardware": put flash memory in a PCI slot to hold the "continuous
status and images" data.  It would need it's own driver so that turning this
on wouldn't enable USB drives.  Needs research but likely doable...and with
the LiveCD pulled and the thing booting standard Windows, this card would be
able to sit there harmlessly waiting for the next election.  Rendering it
blank at the start-of-day process would be a given, of course...

Got any other ideas?

Come to think, I have one more...it's...going to be controversial...but it
solves a lot of problems too...

f) Since there's going to be multiple voting stations per machine, and since
you'll need to produce an end-of-day report on precinct vote totals...turn
on JUST enough networking to link them all together.  They would talk to
each other, back up and track each other's progress during the day and you
could probably save all the ballot images for the whole precinct to a single
machine's CD burner drive.  Each machine would need 2, maybe 3 gigs RAM so
they could hold every other machine's data too in a continuous backup...but
that's not impractical.  In order to crash the whole precinct, you'd have to
crash all the machines.  Even one could both continue to operate while
holding the votes-to-that-point in it's own memory and would include those
in it's end-of-day CD burn, labeled by directory name as to which machine
each image set came from.  DO NOT have Samba in there, so you're doing pure
Unix-type networking, and...yeah, this is doable.  Probably need RAMdisks at
each machine, that's no problem.  Another benefit: need to produce half a
dozen or more end-of-day CDs?  Fine: burn them at multiple stations.  Each
can write out the same disk including every machine's images, sorted by
directory. With a burner on each, you've got serious hardware redundancy on
the burn process.

To make this work, you might have to have up to eight boot disk types made
up, labeled one through eight.  Each is identical except they have different
IP addresses for up to eight stations per precinct?  There's probably other
ways to skin that cat, this is just the first off the top of my head.
Another: code the same boot CD so that it looks for a DHCP server, if it
finds one it will grab an addy, if not (as in, it's the first to start) it
creates a DHCP server?

---

What were your plans for uninterruptable power?  Various low-power mini-PCs
are available based on the micro-size motherboards; something like that,
even with two optical drives plus a flat touchscreen, could live for several
hours on a typical server-class UPS.  The current touchscreens have battery
backup for a reason...thoughts on that?  A touchscreen lappy might indeed be
the answer here depending on how external USB optical media drivers work...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tfug.org/pipermail/tfug_tfug.org/attachments/20080512/d9a3bae9/attachment-0002.html>