In the recent regional election of South Korea, there was a district where the winner won by a single vote. The runner-up appealed the decision, took the ballots to the overseeing committee, and the committee re-examined individual contested ballots and decided one of the ballots previously considered invalid should count for the second person, making it a tie and (according to some tie-breaking rules) changing the winner.[1]
You can't get that kind of transparency with voting software. It's worse in every way.
[1] Link (in Korean): http://news.jtbc.joins.com/html/712/NB11663712.html
It solves some problems that have been introduced over time in most election systems. Primarily, time to count/verify, ease of access and verifiability. To say that paper doesn't have these problems shows a lack of understanding or a willful intent to mislead. The boxes of uncounted votes from the Bush/Gore election (https://www.theacru.org/horace_cooper_bush_v_gore_redux/) were a watershed moment that could have affected change beyond the locality.
> Paper ballot is a perfect technology once you introduce optical readers, and when in doubt, you can always re-count everything again.
There are weaknesses with transport or tampering the same as any mechanical recording or electronic recording.
It's important to narrow the intent of a typical modern voting system, with "should haves" rather than hand waving away useful tools.
* Votes should have only been counted from voting membership (registered voters, for example).
* The intent (choices)/member information should have confidence that this data is opaque to inspection without a private/public key respectively. Yes, voters would have to generate their own, as that's an attack vector.
* A voting member should have the ability to track that the vote was counted at all in a given race via a reversible process, which would necessarily include the public and private key.
> You can't get that kind of transparency with voting software.
You can, but the US wont. It's an important distinction that is patently obvious.
Today, most vote tracking systems are electronic, although the ballot was paper. What's the point of half the process being paper? The US government is too inefficient, demotivated, and lacking the impetus to retrain the populace to make any system that is reliable.
Of course using paper doesn't magically solve away your problems. The point is that paper-based systems without these problems do exist in the world and they've been successfully used for decades. You just have to copy the successful ones.
Or, put another way, if your government is too incompetent to run paper-based ballots, using electronic system won't make them suddenly competent either.
> There are weaknesses with transport or tampering the same as any mechanical recording or electronic recording.
The really really really nice thing about paper is that the required size of the attack gets proportionally large as stakes get higher. If you try really hard, you can probably sneak a few votes and change one of the twenty town council members, but does anyone care? On the other hand, to hack a presidential election you will have to exchange at least a thousand boxes or so. With a thousand co-conspirators. While everyone is watching.
...And if you're worried about organized gangs replacing a thousand ballot boxes on your election day, you have more problems than voting systems.
> What's the point of half the process being paper?
That it works. Technology is not meant to be cool; it's meant to work.
The US certainly does. Should we throw up our hands and call it a non-issue? I don't think so.
I would keep using the paper system that we have on Spain. It's secure and confiable, as a lot of eyes tare watching that no body is doing something dirty. The recount is done by a few random citizens plus a few political parties representatives watching it. And it's fast. Usually takes 3-4 hours to know is who win.
Voting is fundamentally simple. People have been doing this for thousands of years, and it's intuitive how it should work. People mark ballots (in private); people count ballots (and then other people count the same ballots); the ballots aren't destroyed until the vote is finished; everyone calls each other and figures out what the total is. The amazing thing is anyone can look at what goes on and say "yep, that looks right", or "hey, I don't think they're supposed to do that…".
The whole thing needs a pretty significant human effort, but, again, people have been doing this for a long time, and large numbers of those humans can easily be volunteers. Also, that human effort is how you build a democracy. It is not a problem that needs to be solved.
As soon as you add software, you've added hundreds of layers of complexity to what was a very simple problem. You've turned it from a democratic, easy to follow system, to something that very few people can have anything to do with. It's like replacing letter writing with Facebook. Sure, you've made the surface act of communicating easier, but to do that you've added an ocean of complexity that nobody understands.
After every airplane crash, there's a major post-mortem. The root causes are ferreted out, as deeply as possible, in a blame-free way - and the regulations are updated and followed by the entire industry, enforced by laws.
What happens when your system has a 30 minute downtime? There's a meeting, someone suggests running your code through a linter or bumping log levels or adding another unit test, everyone high-fives and you wait until the next downtime - and that institutional knowledge doesn't leave the company, sometimes not even the team. Sometimes, it barely registers with the team members, who then quit the company and go and write voting software.
Part of it is that our industry is still relatively young - although, not that much younger than the aviation industry. But a bigger part is that for the most part, it's very strongly segmented, and most of those segments aren't responsible for people's lives.
1. For any piece of software, a person in the right position should be able to sabotage it. Ken Thompson's Turing acceptance piece (Reflections on trusting trust) showed a trivial example of sabotage...
2. It is REALLY difficult to diagnose software while it is running.
3. Risk vs. Reward. Planes have tremendous performance characteristics versus boats or cars. Elevators provide a means for disabled people to get to different levels on a building. But in terms of voting we're trading the security of paper ballots (which humans have spent centuries putting safety measures on ballot stuffing) for convenience.
4. The potential number bad actors with voting is high. While the number of people that want to alter a plane or elevator for nefarious reasons is hopefully limited.
5. Political legitimacy is a very important concept for governments. In democracies, their legitimacy is largely based on ballots. It is really bad for citizens to question the outcome of an election.
Voting software needs to solve adversarial distributed trust across hundreds of thousands of polling stations. That's way harder than distributing control across three cooperating, redundant avionics packages. Really, it's an unsolved problem in computer science, but that doesn't stop people from selling solutions...
Number 2 is the cost of failure.
The worst case scenario for avionics software is a plane crashes and everyone on the plane very publicly dies. An engineer is unlikely to be motivated to cause this on purpose, and if they do then everyone knows about it immediately.
The worst case scenario for voting software is a single engineer gets control over the political direction of the entire country, and nobody notices, ever. There's a ton of motivation to do this.
I think it's better described if we distinguish between functional safety and security. While the avionics software engineer is interested in functional safety and must mostly not be afraid of smart attacks, the voting software developer (or software developers in general) must mostly expect that his system gets attacked by smart attackers.
Although you can do distinguish between both, it's kinda sounds like a lame excuse for me. I think the real reason is, that computer scientist still suck at building correct and secure systems. There is not that amount of funding in computer security research as it should be (like in functional safety).
But In a vote, not everybody wants the same. As a mayor / senator / etc., I want as many votes as possible, and so do my opponents. You can't trust anybody, as the expected outcome is different for everyone.
In contrast to voting, the majority of a (democratic) society wants to have a reliable and trustworthy way of voting.
They are not the typical customer, though.
> In contrast to voting, the majority of a (democratic) society wants to have a reliable and trustworthy way of voting.
Honestly, I'm not even sure to what extent that is true. Give somebody the opportunity to vote twice (illegally, but with the guarantee of not being caught). How many people would refuse, arguing that their voice is not worth more than anyone else's and that it would break the system?
You cannot do that with voting software. To verify the result of a software-based election, you would have to compare the vote counts the software reports with the actual vote counts. But if you knew the vote counts, you wouldn't need the software anymore.
There a proposals to get around this issue by storing each voter's decision so they can verify that their vote was counted properly. That would abolish the secret ballot, making it a horrible idea.
Even if there were a software-based voting system that could be verified by experts, it would almost certainly be too complicated to be verified by the general public.
But how do you trust they are reliable? How do you verify them? How do you verify the surrounding systems? It is a dead giveaway if planes start falling out of the sky that something is wrong. Not so when someone steals an election.
If you want a good password hash you don't go for a fast hash that can be implemented in hardware. You go for a really slow hash that is hard to compute. I think this worse is better approach applies with voting systems. You really don't want them to be efficient. Optimising for efficiency takes away some of their other good properties. Paper voting is incredibly inefficient compared with machines and that is why it is so appropriate.
Planes and elevators are not connected to an internet, unlike most voting machines, making them harder to hack into.
Also, when people hack into planes/elevators the hack will quickly get noticed and thus the exploit will get fixed pretty soon. With electronic voting machines the hack could remain undiscovered for years since there's no clear visible sign that the machine has been hacked.
Most likely some computer somewhere in the chain of voting machine counts -> official "verified" vote totals is connected, but you could say that of vote rolls coming from manual punch ballots as well.
A lot of people suggest the solution is for electronic voting machines to produce at least an actual vote paper trail, but I don't see that helping as a hacked machine could spoof those just as well as bits.
In the case of a voting machine, who are you trusting? The state governments and some random government contractor. What are their incentives? What is their track record?
This is conjecture on my part, since real lives aren't on the line, I would also imagine that error checking isn't held up to to the same standards.
The algorithms required to do it have been invented, so in a sense technical problem and has already been solved. Look up "end to end verifiable voting". Turns out that Ken Thompson's "reflections on trust" don't apply to these systems: you can run them on utterly untrusted hardware. They use cryptography or course, and like a lot of cryptography (eg, zero knowledge proofs) it first looks magic, but when you take the time to understand it it's just very clever.
Which leads you to the first difficulty: we are talking something more more complex than public key encryption. It adds steps and costs. Inventing a user interface usable by ordinary voters that masks the underlying complexity is major challenge involving the both a lot of new software and new hardware. Still, it has been done. https://arxiv.org/abs/1504.07098
Which leads to the next difficulty. It's not at all obvious to the layman how those extra steps and costs these systems require solve the problem. In fact unless you have an analytical engineering type mind, understanding it may well be beyond you. Which is a problem, at least in Australia, because the people who run the electoral systems are bureaucrats who expertise lies in building a system out of 1000's of unreliable newbies in an unfamiliar role that somehow reliably and incorruptibly counts and collates votes to deliver a timely poll outcome. When you reflect on it, it's an amazing feat of human engineering. These people seem to be acutely aware of sorts of ways humans can go wrong and working around it. Unfortunately they are bloody hopeless at understanding how computer systems go wrong.
It worth reflecting on the difference. Human voting systems are most vulnerable to what computer people call "retail failures". Retail failure occur at or near the ballot box - people voting twice, ballot box stuffing, boxes going missing. It requires many small interventions involving many people. Once the boxes get to the counting room there are so many people watching the process fraud becomes much less likely. Computers remove that central oversight - the thing that does the counting becomes an opaque box. Failures at the back end are called a "wholesale failures" to use the voting lingo. If you aren't very careful, a wholesale failure can mean a single person (a programmer) changes a couple of lines of code to in a way that Ken Thompson's reflects of trust tells us can be undetectable, to alter the outcome of an election. Wholesale failures look completely different to retail failures, but can be even more damaging that rampant ballot box stuffing.
The voting systems developed in Australia weren't a technical failure. They were used in real elections, and did work. But they failed nonetheless because in the end they weren't deployed beyond a few test runs. The reason they weren't deployed is the people who ran the elections where given two choices - one by a commercials companies and the one I've described which was developed by cryptographers and engineers in conjunction which disability groups. The first was very pretty, had a slick UI, and came with ironclad commercial guarantees about their robustness from the suppler. The second was more complex, cost more, wasn't so pretty, and came with a through cryptanalysis done by experts which spelt out all the failure modes and their likelihood. If you are a bureaucrat used to working with people is used to making reliable systems by accumulating interlocking promises from said people and utterly unfamiliar with making systems reliable with mathematical proofs - which would you choose?
So they chose the commercial system for mass deployment (I think there were all from US suppliers), and of course in doing so utterly pissed off the very clever academics and engineers who built the home grown system. They were so pissed off that they broke the commercial system on the first night with a wholesale attack - not literally, but demonstrated how they could have hacked it to obtain any outcome they wanted, without the bureaucrats in charge knowing. https://theconversation.com/thousands-of-nsw-election-online... The bureaucrats responded to this activism by labelling it "great marketing" and threatening to prosecute the academics and engineers who proved the commercial system was insecure.