Estonian E-Voting Source Code Made Public
news.err.ee
news.err.ee
https://github.com/vvk-ehk/evalimine/blob/master/ivote-serve...
> By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.
Some of us fork just so we can security audit the code once and then have a safe place to clone from.
Oh, and cool its made in python and not some enterprise java or .NET :)
I'm starting to get sick of this "ruby/python/nodejs = cool, java/.net = slow bloated enterprise crap for men with suits" attitude that keeps reappearing here on HN.
Whether your work environment is cool, whether your code is decent and snappy, all that has very little to do with your programming language choice. Admittedly, if you compare modern Ruby to VB6 you might conclude that VB sucks, but that's an unfair comparison since the technologies are a decade apart. It's like saying Python rocks because you hate COBOL.
You can work at a scrappy startup and code lean C#, and you can work at a bureaucratic departmentalized hell and code AbstractProxyProviderFactoryProviders in Python.
And, yes, you can even work at a bureaucratic departmentalized hell and code decent Python. Or Java. Or C#. Or Ruby.
Apart from that, I agree with you.
Language pissing contests are dumb. Languages are tools, each serves a specific job.
Actually though, it's rather difficult to run into Mono incompleteness when making a web app these days. Mono's mostly lacking Windows-specific stuff like WPF (UI-framework). Used to lack Entity Framework but that's solved since MS open sourced that. You can take an existing ASP.NET app and there's a very high chance you can just build it with xbuild and host it with Mono's xsp server.
More generally, I do see your point but I believe it's a little outdated; the time that Java apps just had to be built on 200k lines of XML is long gone as well.
It's obviously a matter of taste, but I find it difficult to accept that well-written Python would be easier to read than well-written C#. C# is more verbose in places and less verbose in others. Writing crap code is about as easy in both.
Don't get me wrong, C# is relatively explicit and regular, which does wonders for its readability especially in large projects with many collaborators. But brevity is not one of its strong suits, nor should it be.
I think that's the only place, though.
As noted, Oracle uses the term "enterprise", which I take to imply a corporate approach to language implementation the coincides with service/support agreements and other business models.
For what it is worth, the JVM is second to none for interpreted languages in my book. At the same time, I don't use it and if I ever find myself going back, it will be for Scala. I don't much care for Oracle's brand of innovation (I don't think it is sustainable).
Tell me something, from your perspective: Why should an aspiring technologist learn Java over Python?
EDIT: new Java, for example, looks about like this [1] and that's not all that complicated, even though I would like it more with webflow (technology for describing webpage in term of flows -- each flow is basically FSM with method calls specified on transitions and FMS-wide persistent storage).
[1]: https://github.com/heroku/devcenter-spring-mvc-hibernate
I've never seem a major schism in Java or the JVM on the scale of the split between Python 2.x and 3.x. All my installs require (_at least_) two versions of Python as a result. In fact it was only just recently that Debian/Ubuntu consolidated from shipping with 3 versions of Python to 2.
If you're talking about install base then I guess you're limiting this to client apps - because none of the issues you mention are an issue for server environments... Unless you are running a dozen Java pieces of tech that all require a specific version? In the last 10-15 years I've only ever seen the need for two Java versions once. And that was on AIX. On POWER chips. And it was a vendor, not a technical requirement.
People port languages to JVM for its ubiquity and massive amounts of library code, but I assure you none does it for some technical advantage.
GC has arguably been the best thing Java brought along into mainstream, but it has been a solved problem for a while. The strategy that Java GC adopts, while a natural fit for Java and a host of other procedural languages, is suboptimal for many others.
And for long running processes (where compilation time does not dominate), JIT is of course theoretically superior to AOT compilation.
There are plenty of models for stack optimization. Even if you don't go down the purist track, plenty of approaches use register-allocation and optimize from there. Feels like an outdated CISC vs RISC argument.
People also use the JVM because of it's Memory Model and robust threading.
http://www.onlineaspect.com/2010/01/19/openness-and-security...
I would think in general that it does, but you also would have to be certain that the software actually running on the official voting system is the same as the "open source" version. I think that's a tough one.
At least it's better than the Diebold debacle in the states.
-Estonia has an internet voting system
-Estonia just released the source code to their voting system
Even if internet voting is a terrible idea, a transparent election system is a very good idea, and releasing the source code for your voting system is a big step in that direction.
I think it's a bad idea as well, but like you, I think it's weird to be upset that there are people who want to help achieve the best solution/compromise, in the event that your country's government vote to implement something like this.
I'm as pro-government as the next European, but we can all think of horrible government project failures.
You have to trust the sys admins. And as we all know: something is trusted if it can break your security policy.
Eventually someone has to trust someone to execute correctly. Unless there's some voting system I'm not aware of that doesn't require humans and is easily verifiable at the point of voting by the average voter.
Later, after the votes were tallied, the voter could verify that their ballot was (1) counted and (2) counted towards their chosen candidate. But crucially, all they could verify was that the vote counted towards position 1, or position 2, or position 3, ...
The point is that since the voter couldn't prove to a coercing party that the position they voted for was (or was not) the candidate the coercer wanted them to vote for, they were immune to coercion. They could prove that they voted for position 2, sure. But which candidate was at position 2?
The voter knows the truth because they saw the position list. However, until we have mind-reading technology, a coercing party could only take the voter's word.
[2] http://documentation.heliosvoting.org/verification-specs/hel...
[3] http://www.iacr.org/elections/eVoting/finalReportHelios_2010...
[4] http://www.iacr.org/elections/eVoting/heliosDemo.pdf
[5] https://vote.heliosvoting.org/helios/elections/1df69264-0a48...
1) Observers at polling stations.
2) Sealed ballot boxes.
3) Observers from many parties and neutrals at counts.
4) Physical votes retained and recountable.
It isn't going to be completely secure but if you measure the systems security by how few people you could rig an election with it is an order of magnitude harder [edit: to rig].
How many people can verify a digital check-sum?
In contrast regular people usually have the mental capabilities to count votes.
[1]: http://wijvertrouwenstemcomputersniet.nl/images/9/91/Es3b-en...
I'm not a security expert, how effective could that be in providing this kind of verification?
"I examine the question of how to design election-related software, with particular attention to the threat of insider attacks, and propose the goal of simplifying the software in electronic voting machines. I apply a technique called prerendering to reduce the security-critical, voting-specific software by a factor of 10 to 100 while supporting similar or better usability and accessibility, compared to today’s voting machines. Smaller and simpler software generally contributes to easier verification and higher confidence.
"I demonstrate and validate the prerendering approach by presenting Pvote, a vote-entry program that allows a high degree of freedom in the design of the user interface and supports synchronized audio and video, touchscreen input, and input devices for people with disabilities. Despite all its capabilities, Pvote is just 460 lines of Python code; thus, it directly addresses the conflict between flexibility and reliability that underlies much of the current controversy over electronic voting. A security review of Pvote found no bugs in the Pvote code and yielded lessons on the practice of adversarial code review. The analysis and design methods I used, including the prerendering technique, are also applicable to other high-assurance software."
(No, it doesn't solve all of your problem.)
You know, there is a technical solution to that problem:
E-voting sounds intersting in theory, but in practice it is basically not worth the trouble. It is way more complex than a regular system with ballots and the only gain is that the results can be published sooner.
Also, if voting is not compulsory, there's a lot less friction to actually go vote from the comfort of your home, whenever you want, than there is to get to a booth and stand in a queue on voting day, it would surely result in a higher turnout.
I'd be interested to see if electronic voting fixes that, or makes it worse.
(2) Slot machines are already protecting millions upon millions of dollars from countless people who would love to be able to modify those machines' behavior.
(3) A backup-paper trail would reduce error and allow for recounts. You vote, a receipt gets printed, you confirm that the printed paper represents your vote, and you're done. (The paper stays with the election commission)
2) Yes but the people who control those machines don't want to modify them (they want some winners for publicity but mostly losers and they are preconfigured for profit without modification).
3) If the receipt indicates your vote this opens the voter to bribery or coercion. If it doesn't how does it confirm that you vote was correctly recorded. Even if it does indicate your vote it is still non-trivial to confirm the validity of the election from it. You basically need to publish all the votes (with receipt numbers) and anyone whose vote doesn't match their receipt could flag it as rigged. This doesn't do anything to prevent digital ballot stuffing though.
There difference is motivation. If a slot machine pays out too much, the company that makes them won't get any more business. If a voting machine favours certain candidates, those candidates benefit from letting that continue (if they weren't instigating it to begin with) and often they might have been the ones in power when they voting machines in question where chosen.
> (3) A backup-paper trail would reduce error and allow for recounts. You vote, a receipt gets printed, you confirm that the printed paper represents your vote, and you're done. (The paper stays with the election commission)
This I agree with, and it would satisfy most concerns with electronic voting if you combined it with paper recounts of some random districts and, say, and districts with small margins or unusually large shifts.
Focusing all that much on the security of the voting machines is a sideshow, IMHO. You need some level of security, but pretty much any security mechanism you introduce will be inferior to recounts based on receipts collected using tried and true methods of paper, sealed boxes and independent observers.
Focusing on a solid recount solution that includes rules for when to trigger automatic manual paper recounts won't just catch malevolent interference with machines but also reduce the chance of problems due to bugs, hardware and software failures and all kinds of other problems.
But of course it'll cost more than switching to a purely electronic system, and that extra money won't go in vendors pockets.
Right now, we have to have presidents, prime ministers, even kings; making all the big decisions for us because that was the only practical way.
E-voting makes it possible for the population to be consulted on any major decision. This, IMHO, is the reason it's so unpopular amongst politicians.
Right now in the UK, for instance, MPs get to vote on their own salary increases. Wouldn't it be nice if they were obliged to ask the voters instead?
Recent years have seen several unpopular wars begun by Western countries - if political leaders had been unable to start those wars unless they'd had majority approval from their populace, the world might well be a more peaceful place right now.
E-voting is something with a lot of promise. But if diminishes the power of the people who would have to implement it. So don't expect to see it widespread any time soon.
There are probably other problems, but I don't think this one is small.
You could easily make a rule that MPs can't raise their own salary without changing the fundamentals of a representative democracy.
I have no clues about potential issues or failure modes of this, but the concept is interesting and - I think - worth discussion.
That it doesn't match Stallmans definition of "free" doesn't mean that it's not open source.
I would expect in my country anyways that any online voting would be DDOS'd by idiots looking for a soap box the media will pay attention to and create a huge debacle resulting in them scrapping it and forcing a regular ol' paper vote.
In the US, we officially supported secret ballots in 1892. Still, I wonder if we all found the strength to open up the ballot, if that wouldn't eliminate some of the viability of voting fraud?
I'll start, I voted for Obama in 2008 & 2012.
Secret ballots make it easier to pull off.
How so?
An open ballot could have prevented this.
That being said, buying votes directly is illegal. If ballots were open, and someone bought votes, there would now be a paper trail.
As an aside: as a failure mode, I'd rather see vote selling than punishment or torture.
[1] Audited, fired from a government job, beaten, not to mention social, religious or family pressures to vote in a particular way. The reality or fear of these things could influence elections if not so much in the West but if these standards were adopted where elections are a little more life threatening (I'm thinking of Kenya but there are probably many other examples too).
Secret ballots make it even easier to pull off.
The secret ballot makes vote selling unreliable, because it's impossible to prove whether someone has voted as promised.
Do you mean that the vote selling is offset by ending other forms of voting fraud? Other forms of voting fraud are incredibly rare.
* Release of E-Election Software Code 'Did Not Go Far Enough' http://news.err.ee/sci-tech/940d2015-ffe1-4c9f-98e8-6fc60935...
* Architect: E-Election Code Should Not Be a Free-for-All http://news.err.ee/sci-tech/7f244d47-86ee-41bd-a544-87bd756b...
Unless I'm mistaken, I can't find any tests though. Maybe they didn't release it, but it's a bit worrying.
Of course it's not reliable, but for a quick heuristic I've found it to be quite well correlated with the quality of the code.
https://www.youtube.com/watch?v=izddjAp_N4I
I think they had a website for it, too, but I can't find it right now, and don't remember how it was called exactly.
It isn't clear from the talk, that:
- you cannot inject votes digitally (within parts of the system) - you may only verify your own vote, and may or may not know about "extra" votes, especially under low turnout, which is very frequent (the euphemism is "democratic deficit")
- supersedes chain voting: it is not clear, that voters cannot be bribed, where the briber can ask for your receipt to verify your voting (currently this is done by buffering voting slips: the first is taken out, filled out in front of the briber and exchanged for the clean copy inside the booth, which in turn is taken out etc.).
True?