Skip to main content

Open and closed Source voting

In several countries voices are raised against the use of voting computers. The latest objection was raised by the CCC in germany. According to security analysis, voting machines are insecure, and allow for untracable manipulation of voting results and voter privacy. The software can be exchanged and votes could be manipulated without any traces. The systems used for voting in Germany are very similar to those in the Nederlands. Similar objects were raised before in this country. Andy Müller Maguhn wrote:
Die Bauartzulassung der Nedap-Wahlcomputer ist nach den nunmehr vorliegenden Forschungsresultaten hinfällig. Das Bundesinnenministerium muss daher die Zulassung entsprechend § 3 Absatz 3 der Bundeswahlgeräteverordnung widerrufen
It does not surprise that similar story are percepted in the USA, where some rumour around the company "Diebold Election Systems" raised, after a group of college students found some memos about the poor security of the system from developers of this company, which somehow sliped onto a public area of the companies website.

After the companies lawyers tried with the help of the "Digital Millennium Copyright Act" to force the university to remove these memos from the servers(yes they are copyrighted material...) the sutdents had to use peer to peer file shareing software to keep the memos online.
The NY Times wrote in an article:
The files circulating online include thousands of e-mail messages and memorandums dating to March 2003 from January 1999 that include discussions of bugs in Diebold‚s software and warnings that its computer network are poorly protected against hackers. Diebold has sold more than 33,000 machines, many of which have been used in elections.

Now a debate araised around the question wheter voting software should be open source or closed source, to assure maximum demoncracy. While I think that one should also keep in mind that the main problem of demoncracy is missing participation, I am convinced that an open source solution is the only appropriate way to ensure a secure voting process.
Clive Thompson wrote:

So now you're caught up. The reason I give this bloated preamble is to point to the real solution: Open-source software.

As the Diebold scandal illustrates, it's incredibly dangerous to let a private company develop proprietary voting software. If they "own" the code, they'll keep it a secret. That means we'll have to trust them that the software is secure. If they're lying to us -- or, more likely, if they're well-intentioned but just unable to realize how buggy their code is -- democracy is screwed.


Open source software could be manipulated by enemies of demoncracy, but that, at least would show up immediately, and it is an advantage of open source software, that the participants are not bound by any contracts or employers, and may talk freely about the problems of the software without the vendors commercially motived blur.

I therefore disagree with Barry Briggs, who answers to Clive Thompson:

I don't think it's perfect at all. Open-source rests on several cornerstones including programmer anonymity and zero accountability. What if we were to find out that a key contributor to our voting machine software was a member of Al-Qaeda?

In fact, the last people I'd trust to verify the correctness and trustworthiness of something as critical as voting machine software would be a loose group of international programmers who could care less about the integrity of our republic.


And who will be eager to write such software? Of course not the enemies of demoncracy, but those who realize the very value and importance of free elections. And it is really motivating to be part of the team that wrote the software, that drives a vital part of the election process.

Links:

Comments

Post a Comment

Popular posts from this blog

Learning Haskell, functional music

As you might have realized, I started to learn Haskell. One of the most fun things to do in any programming language is creating some kind of audible side effects with a program. Already back in the days when I started programming, I always played around with audio when toying around with a new language. I have found a wonderful set of lecture slides about haskell and multimedia programming, called school of expression. Inspired by the slides about functional music I implemented a little song. Ahh ... and yes it is intended to sound slightly strange . I used the synthesis toolkit to transform the music to real noise, simply by piping skini message to std-out. I used this command line to achieve the results audible in the table: sven@hhi1214a:~/Mukke$ ghc -o test1 test1.hs && ./test1 | stk-demo Plucked -n 16 -or -ip Sound samples: Plucked play Clarinet play Whistle(attention very crazy!) play As always the source... stueck = anfang :+: mitte :+: ende anfang = groovy :+: (Trans ...
2 comments
Read more

The purpose of the MOCK

In response to a much nicer blog entry, that can be found here . There are actually several distinct "tests" that make up usual unit tests, among them two that really do stand out: one kind of testing to test method flows, one to test some sort of computation. Mock objects are for the purpose of testing method flows. A method flow is a series of message transmissions to dependent objects. The control flow logic inside the method(the ifs and whiles) will alter the flow in repsonse to the parameters of the method call parameters passed by calling the method under test, depending on the state of the object that contains the method under test and the return values of the external method calls(aka responses to the messages sent). There should be one test method for every branch of an if statement, and usuale some sort of mock control objects in the mock framework will handle loop checking. BTW: I partly use message transmission instead of method invocation to include other kind...
2 comments
Read more

Keys, Values and Rules: Three Important Shake Concepts

The title was a click-bait! This article will actually try to explain five instead of three important notions in Shake. These are: Rules Keys Values The Build Database Actions This short blog post was inspired by the hurdles with my Shake based build, after the new Shake version was released, which had breaking API changes. Jump to the next section if you are not interested in the why and how of this blog post. Shake is rule based build system much like GNU make. Like make it is robust, unlike make, it is pretty fast and supports dynamic build dependencies. But you knew all that already, if you are the target audience of this post, since this post is about me explaining to myself by explaining to you, how that build tool, I used for years, actually works. Although I used it for years, I never read the paper or wrapped my head around it more than absolutely necessary to get the job done. When Shake was updated to version 0.16.x, the internal API for custom rules w...
Post a Comment
Read more