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.

It's the time of the year again: You have 2 more weeks to submit a great proposal to the biggest and baddest MySQL Conference: Percona Live MySQL Conference and Expo 2013 (Santa Clara). Like many things in the MySQL community, this conference has also gone through a transformation over the past 3 years. But last year the growing pains and uncertainty ended with Percona putting up a great show. Attendance was up again (over 1000) and there was a sense of energy and excitement for the future of MySQL. If you are like me and like to dwell in nostalgia (so that you can get into the right mood for submitting great proposals) my coverage of last year's conference is found here: part 1, part 2. (If you don't care about the nostalgia, remember that speakers get into the conference for free!)

Over the years many blog posts have been written about how to submit a great proposal for the MySQL Conference. By myself, Giuseppe, Baron, Shlomi, just to name a few.

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.

Attached are the slides for my MySQL Connect talk Evaluating MySQL High-availability alternatives, which I will present today at 14:30 at the MySQL Connect conference.

A bit unusually I'm posting the material ahead of the talk. The point of the talk is about evaluating each alternative from your own perspective. With that in mind, if you're at the talk with your own laptop, feel free to browse the slides at your own pace from here.

Simon Phipps, who's Computer World UK blog isn't aggregated on Planet MySQL, has a blog post which reveals the truth behind the missing MySQL test cases that many of us commented on some time ago (including myself). You can read Simon's blog post here.

As you remember, there were various things that happened (or rather ceased to happen) during the Summer which led to people complaining that Oracle's MySQL is closing down. As a result of the uproar, source code trees at Launchpad were immediately refreshed. Otoh, there was never any public explanation why test cases for new bug fixes are withheld.

In the Matrix movie there is a scene where the heroes visit a spiritual councelor, and amongst the people in her waiting room they see a little boy, dressed like a buddhist monk, who can bend a spoon just by looking at it. When they ask him what he does to bend the spoon, the boy's answer is: "There is no spoon". And if you watch the movie to the end, you will see that he is right. (In that spirit, if this post is too long to read for you, just skip to the last paragraph for the answer.)

The title for this blog post is of course inspired by Baron's "Is automated failover the root of all evil?", which is a commentary on GitHub's detailed explanation of their recent Pacemaker-induced downtime. Baron makes a good question, but the answer is deeper than suggested by the question. The problem is not the automation, the problem is the failover.