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.



Popular posts from this blog

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:
RulesKeysValuesThe Build DatabaseActions
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 was removed. Until then I w…

Lazy Evaluation(there be dragons and basement cats)

Lazy Evaluation and "undefined"
I am on the road to being a haskell programmer, and it still is a long way to go. Yesterday I had some nice guys from #haskell explain to me lazy evaluation.

Take a look at this code:

Prelude> let x = undefined in "hello world"
"hello world"

Because of Haskells lazyness, x will not be evaluated because it is not used, hence undefined will not be evaluated and no exception will occur.

The evaluation of "undefined" will result in a runtime exception:

Prelude> undefined
*** Exception: Prelude.undefined

Strictness means that the result of a function is undefined, if one of the arguments, the function is applied to, is undefined.
Classical programming languages are strict. The following example in Java will demonstrate this. When the programm is run, it will throw a RuntimeException, although the variable "evilX" is never actually used, strictness requires that all
arguments of a fu…

Erlang mock - erlymock

The project has evolved and can be found here: ErlyMock

Some features

Easy to use
Design based on easymock
Works together with otp: can be used even if the clut is called from another process, by invoking mock:verify_after_last_call(Mock,optional: timeout)
custom return functions
predefined return functions for returning values, receiving message, throwing exceptions, etc..
erlymock automatically purges all modules that were mocked, after verify()
Custom argument matchers:

%% Orderchecking types: in_order, out_of_order, stub;
%% Answering: {return, ...}|{error, ...}|{throw, ...}|{exit, ...}|{rec_msg, Pid}|{function, Fun(Args) -> RetVal}
expect(Mock, Type, Module, Function, Arguments, Answer = {AT, _}) when AT==return;AT==error;AT==throw;AT==exit;AT==rec_msg;AT==function ->
call(Mock, {expect, Type, Module, Function, length(Arguments), {Arguments, Answer}}).

%% this version of expect is suited for useing custom argument matchers
expect(Mock, Type, Module, Fun, …