election software

[Nigel Jones]

On Wed, 2008-10-08 at 16:32 -0700, Toshio Kuratomi wrote:
> > 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.)
> > 
> Probably not... but not necessarily no :-)  That's probably a board
> question and I'm an infrastructure guy instead.  (This is a list where
> Board Members take in information, though, so they can make their
> preference known :-)
This is (in my opinion) not an option for us.

> >> 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.
> > 
> We probably would want to tie to the existing auth system.  Currently we
> allow people to join groups while elections are in progress and they get
> to vote in those elections.  Keeping track of group joining while an
> election is in progress and sending out new one-time passwords wouldn't
> be the best in this situation.  Also, I'm pretty sure that some of our
> users won't like the fact that the passwords travel via email. (We could
> encrypt with GPG if we have a key on file or something but that's extra
> work that when we'd be happier to put the extra work into getting our
> authentication working with the app).
We do have some weird requirements at times for allowing people to vote,
at least with doing everything ourselves we can check on the spot
in-app.
> >> 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.
> > 
> <nod>  That's what I'm thinking.  Now we haven't had complaints yet
> that
> any of the web sites we have are not accessible this way but there's
> only one (useful to packagers only) that is not usable in lynx.  And
> it
> is a goal of ours to have accessible web apps.
> 
> Is a command line front end a possibility?  Does your app have a json
> or
> xmlrpc that we could tap into?
> 
> In terms of actually using the Helios Voting app for Fedora Elections,
> you want to talk with Nigel Jones as he's the coder behind our current
> voting app.  I'm just raising issues that we'll have to address if we
> choose to switch.
Why change to something else when what we use now is proven to work?  By
developing specifically for Fedora Project we know/knew that:
 * It's going to meet any requirements that our groups have
 * It's going to integrate with our Infrastructure perfectly
 * It was going to counter other issues with the old voting application

In addition, as the elections application doesn't do/never will use any
super-weird code, unless something changes in the TurboGears framework
(which we can adapt to), in the currently deployed state, it could work
for years.  As a result, the maintenance requirements are very low.

Now in an earlier point there was something about "reinventing the
wheel" etc, how does nominating candidates in-side the application
'reinvent the wheel', it's a natural 'election' process, in fact it
makes it easier, this is what I'm concentrating on now.  Making the
whole process easier for the end user to save them from 15+ minutes of
digging around to work out where everything is/should be.

I think the time spent trying to migrate to a different system would be
a waste, we know that our code works, it gets tested every step of the
way and the few features we need *work*.  Yes I'm building in new
features, but the end goal is to make the process better.

- Nigel
-- 
Nigel Jones <dev at nigelj.com>