Yesterday I described my first ideas at mapping the preferential voting method used in Liquid Feedback, to an approval voting method as supported by Helios Voting.

After writing it I had a Heureka moment and went back to check some details on how Liquid Feedback, and in particular the Schulze method actually works. It turns out it is not necessary at all to keep a record of the +N ... 0 ... -N scores given to each vote, this is merely an implementation approach used in Liquid Feedback. The only thing that is really needed is just the pairwise comparisons of all alternatives. This is stored in Liquid Feedback in the battle table. In fact, that is precisely what Solon delivers back to Liquid Feedback as results of the voting.

It's been a while since I last did any hacking on Solon Voting. Solon is my project to implement secure e-voting for delegated democracy platforms. You can read previous blogs here.

When I started Solon, I was first focused on just tweaking Liquid Feedback in order to enable use of cryptographically secure e-voting algorithms. I wasn't aware that an open source implementation of a homomorphic e-voting algorithm actually exists. But then a couple of people introduced me to Helios Voting. This has been great news. What remains now is basically to glue together Helios with the already existing Solon-LiquidFeedback combination, and we will have a first ever cryptographically secure voting solution for delegated democracy. Of course, this is a very rough prototype, but it will properly encrypt the votes and will produce verifiably correct results.

Last week I had some vacation, so I finally had time to play with Helios a bit more. The results of this week's hacking are now committed on Github.

It's been a few months ago that I wrote a series of blog posts about Solon Voting. Solon is a project I started in July to implement cryptographically secure e-voting for direct democracy platforms, in particular Liquid Feedback which is used by the Pirate Party and other organizations in Central Europe. In the previous posts I already covered how delegated voting works, and how to divert the data flow of Liquid Feedback so that the voting phase could be handled by a cryptographically secure e-voting module. In the last post I then went on to look at requirements for secure e-voting. Those requirements are frequently referenced in this post.

Having laid out the requirements, I want to spend this post on briefly talking about the algorithms that exist for cryptographically secure e-voting. This is very superficial of course, it's intended to be layman understandable for those that don't really want to read the highly mathematical academic papers on the topic. If you do want to read academic papers, you can find lots of them on Google Scholar, just search for "e-voting" and you're all set for months to come! (No, I'm not qualified to recommend you any good papers. Just go and Google for something just like I did and if you find something interesting, let me know!)

In my previous blog posts about Solon I have mostly focused on the high-level interaction between Solon and Liquid Feedback. Now it is time to dive into the good stuff: the cryptographic e-voting algorithms that scientists have been developing since the 80's. But first, we need to understand our requirements. What does it mean to develop a secure e-voting algorithm?

Most academic articles on e-voting algorithms will begin with a recital of requirements for a secure election or secure voting. The list is quite long, so sometimes an article may omit some of these, but there is a well established consensus that what I will write about in this post is what a secure election is about. I have taken this list from a really well written overview of different e-voting algorithms: "A framework and taxonomy for comparison of electronic voting schemes" by K Sampigethaya, R Poovendran, Computers & Security, Elsevier 2006. I recommend you read it if you want a deeper understanding on this topic.

In my previous blog post I explained the concept of delegated voting and how to make it work together with cryptographically secure e-voting algorithms. In this post I want to describe actual data flows of Liquid Feedback, and how a secure e-voting system like Solon could be hooked into it. For those of you potentially interested in contributing to Solon, I hope this gives a high level idea of the design.

Everything explained here already exists. The liquid_feedback_patch/ creates these hooks into Liquid Feedback Core and alters the calculation procedure so that it counts the externally provided results. The 0.1 version of Solon is able to support this data flow and gives you a simple UI to cast votes via Solon. The small detail missing is the actual "secure" part, the current version is just a mockup demonstrating the idea. After this post I intend to write more about the Acquisti e-voting algorithm that I intend to implement as part of Solon.

So yesterday I went live with my new project, Solon, which aims to implement cryptographically secure e-voting for delegated democracy platforms, starting with Liquid Feedback.

How delegated voting works in Liquid Feedback

To create a cryptographic algorithm for Liquid Feedback, we must start with understanding how the current (plaintext) voting works in Liquid Feedback. The concept is known as delegated voting.

Those who know me know how excited I am about open source as a phenomenon. I contribute to open source projects myself, but I'm just as excited about non-software incarnations about the same phenomenon. Wikipedia, Project Gutenberg or Open Clipart are obvious projects to mention. "Life in a day is an awesome movie that was mass-produced by thousands of Youtube users all around the world - things like this are only possible through the open source method. It's a bit embarrassing but I even get excited about viral videos and flashmobs.

One area that has not been discussed a lot - nor has there been much to discuss - is government. What would it mean to open source government? Yes, I'm aware of the so called Open Government and Open Data movements. This is mostly about publishing government owned data for public analysis. Social networking has also brought politicians closer to their constituents and thanks to this politicians seem to be more likely to be affected by public opinion (or outrage, as it sometimes happens) than before. All of this is great, and more transparency usually does good for the democratic process. But ultimately I don't see it as a revolutionary new way of government: the same old politicians from the same old parties remain in power while you play with their data.

Heyhey... after a year of hard office work, it's like the good old times again: my blog seems to contain mostly notes of various conferences I've been to :-) (By the way, I also had an interesting trip to Dublin last week, maybe I'll write about that later.)

On Wednesday night I'm off to Notthingam, where I'm attending a seminar titled "The political economy of peer production" organised by the Nottingham Trent University. Excited as I am I became a bit grandiose and chose as my subject the introduction of a system of direct democracy. In other words, I've been thinking I should replace all the current democratic governments we have.