[MG] Direct democracy web-voting software

Jonas Liljegren jonas at aktivdemokrati.se
Thu Feb 2 10:43:14 EST 2012

Please update the page

I'm holding a Skype meeting on Tuesday, feb 7, at 14.00 UCT/GMT by
Skype. Username jonas_liljegren.


This is a selection of posts from
e2d-international at googlegroups.com
that I now also post to
start at metagovernment.org

Software developers should all join the Metagovernment list.


Eduardo Robles Elvira wrote at Jan 26:

I am a member of the Agora Ciudadana development team, the liquid
democracy solution we plan to use in the spanish political party
"Partido de Internet". Here is a detailed technical article about the
system we are developing:

Please read that article to understand the size of our project. We are
collaborating with crytographers from Sweden (the author of
verificatum), and we have also been in contact with Ben Adida from
Harvard, main author of the Helios secure voting system. We are trying
to do it right, but we have a big problem: we are few people working
in our free time in Ágora, and thus its development follow an slow

I happen to also be an entrepreneur, and in Wadobo (my company) we
would be interested in collaborating in the development of a joined
project if we get funding, and I offer help and  time to make the
effort of finding funding. I also have some contacts with pirate
parties and Amelia Andersdotter, pirate member of the european
parliament which might be interested in this kind of project.

I very well understand that companies need to do something for a
living, but I cannot stress this enough: this software must be free
software, open source.


Sven The Barbarian wrote at Jan 28:

It is good to have you talking with the E2D group, Agora look like a
well thought out DD software solution. I think it is great that we work
together to develop a software that can be used by a number of different
parties, and will support this, but want to make a couple of notes.

I do not feel there will be one software that will be suitable for all
parties, some parties are focusing of encryption like Helios and I
believe Agora is strong on this, some parties are focusing on Liquid
software, some parties will want to build in collaborative proposal code
into their voting system. SOL at the moment are looking at creating a
plugin for an open-source CMS like Joomla or Drupal because they believe
it will be simpler to develop an end product quickly and there will be a
wider group of developers who can assist.

I am on the fence at the moment about whether a serious security focused
system is needed or a simpler more user friendly system would be more
sell-able to the public, at this point the most important thing is DD
parties ability to sell their system to the general population, ie: get

Inside the active E2D group of people I am not sure there are many
people who will be able to commit a lot of time to the development of
Agora, we will be able to help a lot in guiding what the end product
could look like but actual coding not so much. Also I do not think any
party has disposable funds to assist on the financial side?

SOL in Australia, who are not active at the moment in E2D, have a couple
of people assisting with their IT, one is currently investigating what
path he plans to take regarding the eVoting program, if you/we could
convince him to help with the Agora system it might help. I have already
passed in your original message to him. For example core code could be
created that is abstracted out from the user Interface, then a UI plugin
could be created for any CMS or stand alone, giving parties a stable DD
base system and flexibility on how they deliver it.


pablo2garcia wrote at Jan 28:

I fully agree with your view points on having and maintaining a
variety of software and initiatives. Our party is not only interested
in Agora or secure voting systems, but it is the one that we are
developping now. So we would love to go on hearing about other sytem
types, make Agora compatible, in code and use, with other systems for
other uses or as you say at the end, making similar systems
compatible. In fact we have been for long thinking in starting a
soft-security Liquid Democracy system ready to use in any webpage,
discussion group, or social net, so we WANT to know what is out there.

In E2D we can discuss the different solutions in how humans would use
it and on technical things around voting and participation and not so
much on the coding part. It would be very valuable to the different
projects to be exposed to such disscussions.

Also spreading the word on the different software solutions taken, and
uniting or begining a dialogue between efforts and initiatives when
they want to take that time.

... In 2-3 months we are starting a: Public call for
"code for democracy" initiative. I will send info on another email.


Sven The Barbarian wrote at Jan 28:

... at the start of this year I created an Internal Voting System for
E2D and it is operational on the site, the purpose of this is to create
a more streamlined process of proposing work to be done internally in
the E2D organization, and builds in a method for all members to be
contacted about and reject any proposals, giving internal admin of E2D a
more transparent consensus method of actioning ideas. I am sure no-one
would reject to you becoming part of that, you can create proposals, be
notified of and accept/reject others proposals. To do this just sign up
an account on the E2D Forum (http://e2d-international.org/forum/) and
email or make a post of your username and I will add you in. ]

You can see development notes of the this system at:

This is an area I have created for pre-proposal discussion of ideas:

Here is a link to the actual IVS system:


Sven The Barbarian wrote at Jan 29:

It does seem crazy that many parties are programming their own software,
and all are stretched in regards to time and resources. I would happily
be involved in a more collaborative approach. There would have to be
agreement on fundamental questions such as the programming languages,
the programming environment, how additions are tested and reach final
builds, we could learn a lot from established open source groups like
the Mozilla foundation or Apache group.

The next step would be to gather from all existing parties what features
they require, skipping the theoretical DD discussion and focusing purely
on the exact tool each party plans on needing, going into fine detail so
all features are taken care of from the outset. It might be that the
features vary widely between parties, in which case the project could be
developed as a set of shared libraries with additional modules that glue
everything together (parties with unique features might have to program
their own modules).

It would be an interesting step forward, especially if we could get the
Agora group, the Gov developers, the SOL people and others working
together on shared code. Maybe even contact groups like the ones making
LiquidFeedback (http://www.public-software-group.org/) and Helios,
although they are pretty well developed systems with specific goals, and
might not like the idea of contributing to new software.


Eduardo Robles Elvira wrote at Jan 29:

My thoughts exactly. I've already been in contact with Ben Adida from
Helios, and I think that the way they're doing it is the way to go.
One of our goals in Agora is having a secure voting system that can
scale to 1 voting per hour with many votes, and Ben Adida redirected
me to Douglas Wikstrom from verificatum which is the fastest mixnet
implementation known to date, to make it scale even more. Here are
some of my tests [1]. Also take a look at the "How to go massive" part
at the end.

I think we could start porting helios to use verificatum, that's
something the author of verificatum want to be done. Then we can add
delegation support (as explained here [2]) to helios on top of
verificatum and then we'll be onto something really nice. We'll
probably have the help of verificatum and helios people, so that'll be
for me like standing on ye sholders of Giants. Note that the
International Association for Cryptologic Research (IACR) has been
using helios internally.

It'd be nice if the different development groups that are eager to
collaborate together in a joint project could held a meeting to know
each other and stablish common goals. Each part would present its
members, their work, their status and come with a list of what they
think is needed, and then we'd try to reach a common ground.

I've proposed this before at Partido de Internet but we didn't get
around to doing it: I propose the creation of a Foundation for a
Liquid Democracy, to foster globally the idea of liquid democracy by
the means of conventions, talks videos etc, and the development of the
tools that enable it. We need to get people to know the concept, and
we also need to continually improve the voting software to always
maintain it secure (as new advances in security fields are made, both
in attacks and defenses) and  to deploy it wherever it can be
deployed: local and national governments, etc.

[1] http://wiki.agoraciudadana.org/index.php?title=Verificatum
[2] http://www.agoraciudadana.org/2011/09/agora-a-virtual-parliament/


Paul wrote at Jan 29:

like Sven said, the people on


have already a liquid democracy website up and running (for the pirates)


Eduardo Robles Elvira wrote at Jan 29:

I know that, we studied the different available liquid voting systems
before starting the Ágora Ciudadana Project =). We discarded their
software because they didn't provide enough security for the privacy
of the vote. The vote in mixnet systems is secret and the server
cannot decrypt it. Also the result is universally verifiable. Helios
Voting voting provides all this, but does not provide massive
scalability nor delegated voting. That's why I think we should use it
as a base.


Sven The Barbarian wrote at Jan 29:

As Paul noted there is some other software out there already, I/we
really need to assess it to make sure we are not re-programming the
wheel. Helios was very interesting because of the level of experience of
the cryptographers involved, I would like to look at it further but it
did seem pretty complex to install, requiring specific Unix environments
and quite a few comments about things not installing properly. I can
envision a complex secure voting system becoming insecure quickly if
errors are made during setup due to its complexity.

The cryptography needs to be separate from the UI and processes such as
delegation, because different implementations will handle these
differently, I am not sure if Helios is structured this way.

I am also not completely won over by the Helios concept that tracking a
key to the final tally represents a secure voting system, the Helios
developers themselves bring up some security failings, mainly universal
to all online voting systems, I made some notes at
http://e2d-international.org/forum/viewtopic.php?f=10&t=153, for me
personally I would approach these dangers by skipping the whole
cryptography user interface, your average voter will not bother with it
anyway, I would offer small community level tallies, which can be
checked by the communities themselves but affording privacy of
individual votes. Communities can then raise investigations if they find
discrepancies. So for what I would implement Helios is overkill
(although it could still be used as the core code with the cryptography
hidden from voters).

That being said I think it is a good starting point, if we are going to
build on existing code we need a structured assessment of it according
to the final product each E2D party needs.

Scalability is important, I think this is something SOL has not
completely considered when they are looking at using a PHP CMS plugin,
easy to program and clean interface, but will it scale to millions of
votes if they find themselves with an elected Senator? I have my doubts,
lower level code like what Helios has (and I guess verificatum) would
more likely achieve this. I have not been able to give a convincing
argument to SOL yet because I have no evidence of a plugin failing in a
large scale environment. SOLs mindset is that once they get to that
stepping stone they will have more resources available to them due to
their success, they would rather focus on getting votes than programming
software, I respect that viewpoint.

A note about calling this a "Liquid Democracy" project might not be
completely accurate, I understand liquid means proxies/delegation of
votes to others, but it is likely some E2D parties (like Canada at this
point) will not have any proxy voting in their initial software, and the
software should be designed to support this, I would suggest a more
generic term along the lines of "voting" or "direct democracy".


Eduardo Robles Elvira wrote at Jan 29:

I can guarantee you there's nothing out there like Agora. There no
secure vote delegation scheme that the cryptographers we've contacted
know of other than the one I've already referred in other messages.
BTW, when I talk about a "secure voting system"  I mean secure as it's
currently understood by the cryptographers, where the vote is secret,
and the tally is truly verifiable (more about that later on this

I like the idea the idea you proposed of having multiple and smaller
votings districts with a different set of authorities on each one.
This is something we have already thought in Ágora in order to make it
scale better and be more resilient to attacks.

About the complexity of installing Helios, well I've done it myself
and it's not that complicated. Of course you need a good administrator
to secure your web server, that's undisputed =) I hope you have one!

> The cryptography needs to be separate from the UI 
> and processes such as delegation, because different
> implementations will handle these differently,
> I am not sure if Helios is structured this way.

That's easy to say and difficult to implement. I don't think that what
you say is a requirement at all, honestly. Security for us is a must,
and we even had a voting about it.

> I am also not completely won over by the Helios
> concept that tracking a key to the final tally
> represents a secure voting system, ...

I've read the notes in the forum that you have referred, and I'm sorry
for having to say this to you but you've reached to wrong conclusions
based on false premises. You say (quote):

"Helios market their solution as "truly verifiable online elections",
and they have some really good ideas about a voter verifying their
vote through to the final tally, but I see holes, some acknowledged by
Helios who advise their software is not strong enough to use in a
political environment:

- Server gets hacked: If the server got hacked it could be made to
return any tally the hacker wants, but still return the correct
encryption information for each voter, the voter believes their vote
was counted correct in the tally."

This is untrue. Not only the voter can verify their own votes, but
anyone can verify the whole process of the tally. Note that the
secrecy of the votes remains intact if at least one of the authorities
has not been compromised. Note also that the frontend web server has
*nothing* to do with the servers of the authorities. One would want as
many authorities as possible. BUT even if all the authorities had been
compromised (and thus the secrecy of the votes too), one can verify
that the mathematical proof of the tally is incorrect: and that's what
is called universal verifiability.

For more information, refer to the published and peer reviewed papers
from Ben Adida in http://adida.net/research/ .  I've personally read
them in order to understand how to make the delegation scheme in Ágora
work and to improve the inner workings of verificatum library. If I
were you I would be more careful before discarding the work of well
known cryptographers - of course if you have any proof of Ben being
wrong, I'm sure the cryptographer's community will welcome the
publication of your discoveries =).

> That being said I think it is a good starting
> point, if we are going to build on existing
> code we need a structured assessment of it
> according to the final product each E2D party
> needs.

Having a software whose only purpose is voting is the best security
scenario. On the other hand, using a CMS PHP plugin is a recipe for a
security nightmare: it's better to do one thing and do it well. CMS in
particular are usually not the most secure web applications out there.

> ... SOLs mindset is that once they get to that
> stepping stone they will have more resources
> available to them due to their success, they
> would rather focus on getting votes than
> programming software, I respect that viewpoint.

I respect that, but as I said in Ágora we're trying to make things
right instead. We want to develop a software that is robust and can
replace the physical votings while having as most security assurances
as possible (as you can see, in some aspects we can even get more
security than in phisical votings).

> ... some E2D parties (like Canada at this point)
> will not have any proxy voting in their initial
> software, and the software should be designed to
> support this ...

Disabling features in a piece of software can be done easily if the
design took it into account from start, but support for delegation is
for us the key feature.


Sven The Barbarian wrote at Jan 30:

I have only touched on the Helios system and do not yet understand its
structure, I admit this and hope to be proved wrong and there is no way
a hacker with control over the central server/s could return false
tallies while returning accurate keys. Helios looks like the most secure
eVoting software available and a good starting point for creating a more
universal software for DD parties. On a theoretical level though I
believe all solutions run the risk of hacking, it might just be a virus
infecting client machines that flips votes, pretty easy to detect but
the possibility or perception of any such threat will be ammunition for
opposition to the DD movement, this is why it should be discussed early
on, possible solutions considered (such as public voting or smaller
demographic tallies), and if we are building a new software package
these features should be incorporated.

 From where I stand I have not done a good enough analysis of the
software currently available to say where it should start, if Helios
proves the best choice I will support using it, but factors other than
security need to be considered, depending on the needs of the parties
involved, ease of installation, simplicity to manage, time to deliver a
finished product, stability, well developed user friendly interface,
these might be more important to some parties than security. I am
guessing Helios probably can offer these or can be rebuilt to, but am
trying to look at this from all angles. If you do not address the needs
of all people involved then the collaborative project will fall apart
and groups will go their own way.

I have touched on this before but I believe a starting point would be to
create a list of questions for all parties finding exactly what they are
planning they need from an eVoting solution, ie how they would implement
the system if they had it right now plus any features they think they
might implement or change to later. High level questions could include
with they be allowing proxies, what voter verification system will they
use, will they allow fluid collaboration of proposals, will they allow a
rated voting system or simple accept/reject votes, etc.. then lower
level questions will include will they put a limit on chained proxy
votes, will the employ degenerative proxies, will they force people
accepting proxies to make their votes public, what type of vote rating
system they wish to use, etc..

There are a lot of possible features if we want to create a
comprehensive package, programming for them all will be exhausting but
we can hone the list down to what will actually be implemented. In
addition we should consider possible future features and structure the
code as best as possible so they can be plugged in at a later date. You
wrote that separating elements in modules, such as proxy/delegation from
the encryption, might be difficult or impossible, you could be right but
I feel if planned for in advance it might be possible.

Delegation is a cornerstone of what you wish to implement in Spain and I
personally believe it is an important selling point for DD parties, but
ultimately it is not a requirement for a DD system. The Canadian parties
vote and rejection of delegation shows that it is feasible some
populations will reject this feature. A non-proxy system can probably
work from the same code as used for delegation, but the delegation code
might unnecessarily slow down or create holes in a non-proxy
implementation. I would suggest a new project be designed to abstract
areas as much as possible, the encryption, the vote processing, the UI
all in separate boxes of code. Coding would probably focus on a vote
processing system that supports delegation, but allow for the
possibility a party that wants no-proxy code be able to create a
different module without having to re-program the encryption or any
other shared code.

These are only my initial thoughts, if everyone else thinks it is not
possible or too complex then I will roll with that.


Please update the page

I'm holding a Skype meeting on Tuesday, feb 7, at 14.00 UCT/GMT by
Skype. Username jonas_liljegren.

It's about coordination of the voting and deliberation software for
direct democracy and liquid democracy.

This will include discussion about funding for the projects.

jonas at aktivdemokrati.se | Göteborg | http://www.aktivdemokrati.se/

More information about the Start mailing list