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.
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.
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.
While back on the Open Core topic anyway, a few notes on how 3 projects have reacted to the debate and criticism of the past Summer.
I personally work mostly in the middleware layer of things, especially databases, so I'm most familiar with the open core practices of MySQL, SugarCRM, JasperSoft and others in this space. So when LWN reported on the open core backlash last Summer, it was the first time I learned that a syslog utility known as Syslog-ng also follows this model. A basic syslog functionality is free and open source software, and there is a commercial version that comes with closed source addons. They have a contributor agreement of course, to make it work.
Except that they have now tweaked their model as follows:
The pre-voting has started in Sweden,and there are 15 days until election day.
Much has been said about open core, but with the OSI coming out squarely against it on the one hand, and Rackspace and NASA creating the OpenStack.org project as a "true open source replacement" for Eucalyptus on the other hand, it seems open core is now much less attractive than it was only a week ago. It seems everyone has now learned what open core is and agrees that it is not open source, nor is it good for open source. (And by "everyone" I mean everyone that really are open source advocates, naturally those who directly or indirectly are trying to profit from open core will continue to promote the model for a long time to come.)
The final question that remains to be answered is, if I know about open core and don't like it, what can I do to help prevent its spreading and rather promote the adoption of true open source?
With my personal experience working for MySQL, I've had a few years to collect some ideas, and would like to share them below. Please add your own in the comments and I'll keep updating this post so it can remain a useful reference.
(Last updated Aug 29, 2010.)