election software

[Ben Adida]

Toshio Kuratomi wrote:
> I'd have to look at the code more, but looking at random files in the
> base/* directory didn't give me a good feeling.  There were comments at
> the top of files like, This code was taken from feedparser under License
> XXX.

I try to be excessively clear about sources from which I borrow code,
but the only times I bring them in by source is when the project isn't
packaged, when I'm using some starting point but then expanding on it,
or when I need a small piece and can't install the rest because of
native-code dependencies. Here's an exhaustive list:

- HTML sanitizer: code from feedparser, with appropriate copyright
notice from Mark Pilgrim.

- number.py and randpool.py for basic number theory in the Python Crypto
Toolkit. The Python Crypto Toolkit includes native components which
doesn't jive well with Google App Engine.

- oauth.py, taken from the OAuth Python library but hacked a bit because
some parts were not quite right.

- REST.py, taken from public sample code to build simple REST facilities
on top of cherrypy. Not a package to begin with.

> There was other code taken from different projects (github is down
> so I can't look at what right now) -- it made that directory look like a
>  packagers nightmare.  If we're not going to use it, I didn't want to
> deal with analyzing it :-)  If we are, then I (or someone else) will
> have to.

So, of course you should analyze the code to your heart's content.

That said, I just want to point out one important feature: this is a
cryptographically verifiable voting system, which means the results are
presented with a mathematic proof of correctness. So, in fact, the only
part you really *need* to review is the verification program: the
client/, crypto/ directories.

I'm not suggesting you ignore the rest of the code, I'm only trying to
highlight the verifiability of the system.

>> Also because of Google App Engine, which has django built in but not the
>> standalone version of simplejson. Thus you see me trying to import
>> simplejson, and if that fails I try to import the one from django.
>>
> The code actually does the reverse of that :-)  Not a big deal, just
> need to switch the failure case (and for Fedora, remove simplejson from
> django bz#464885).

Oops, you are correct about the order. Note that this should go away
when the Google App Engine folks fix their bug (which I've reported to
them), an inconsistency between the platform and the sdk.

> <nod>  I'm not complaining about it, just noting it.  It limits the
> database backends that can be used to the ones that the app has been
> ported to rather than letting the ORM manage database portability.  (I
> love postgres but, as mmcgrath tells me frequently, mysql is much easier
> to administer which makes him much happier :-)

Well, I won't get into a DB fight, but... are you trying to package this
for aptitude-style installation? That's great but it might be a bit
premature for that.

Would you consider running the election at heliosvoting.org and using
the Python verification programs (which you can and should audit) to
verify the election? That should make it quite easy for you (and just as
verifiable.)

Of course, installing it yourself is a perfectly fine option (once pgsql
is supported), just a lot more work and not any real additional
verifiability.

> My basic aim is figuring out how we'd tie the authentication in the app
> into our account system.

1) I would recommend not tying this to an existing auth system: just use
election-specific passwords emailed to folks. Simpler and really just as
good since there is a *public* verification phase where everyone can
check that the hash of their vote is on the public bulletin board.

2) If you really want to tie it to your existing auth system, you could
hack the code or use the OAuth-based API where you build a different
front-end that sends votes to the server via REST calls. I'm working
with a large university that wants to do just this, so we'll have sample
code for this approach in a couple of months.

>>>> I ran into tracebacks creating a new election so I'm not
>>>> sure how it works in practice.
>> Where, at www.heliosvoting.org? Or running it on your own? The pgsql
>> version is not working yet. Do you have the full traceback?
>>
>> You can report and track the bug at: http://helios.lighthouseapp.com
>>
> Yeah, at heliosvoting.org.  I first tried to create an election managed
> by trustees and got a traceback.  Then I tried to create an election
> managed by myself and got a traceback. Didn't explore further.  Since I
> was just evaluating how it stacked up to what we have now, Im afraid I
> didn't file a bug report.  Sorry.

No problem. Can't reproduce either of these right now, but let me know
when you do reproduce them.

> Hmm..... there's upsides and downsides to this.  We want to have
> accessibility for voting if possible so a reliance on java and
> javascript is problematic.  If there's a json or xmlrpc interface, then
> we could code an alternate front-end.

Using Java and JavaScript should not preclude accessibility. Java is
only used for bignum computation, never UI. JavaScript is used to glue
HTML and Java together. The HTML should be easily customizable to be
screen-reader friendly or otherwise accessible.

Now, if you're thinking about a lynx interface, that is indeed a
problem, but it's a problem that gets at the heart of the features
offered by Helios: Helios *needs* the browser to be able to do crypto so
the vote can be sealed encrypted before it leaves the browser.

This is definitely a lot more than an HTML form, I know, but it brings
with it a qualitatively much higher level of verifiability.

-Ben