Let’s get the fish in the barrel out of the way. Voatz are a tech startup whose bright idea was to disrupt democracy by having people vote on their phone, and store the votes on, you guessed it, a blockchain. Does this sound like a bad idea? Welp.
It turned out that they seemed awfully casual about basic principles of software security, such as not hard-coding your AWS credentials. It turned out that their blockchain was an eight-node Hyperledger install, i.e. one phenomenologically not especially distinguishable from databases secured by passwords. They have been widely and justly chastised for these things. But they aren’t what’s important.
To their credit, their system is opt-in, and apparently generates real-time voter-verified paper ballots, the single most important thing about any voting system. But still. We need to step back and ask a question here: why are we trying to vote via an app and collate election results on any kind of centralized system at all? We don’t want to make voting more efficient. Efficiency is not the problem we are trying to solve with elections. The inefficiency of paper ballots and their handling and collation and tabulation is a feature, not a bug.
Voatz were approaching the wrong problem in the wrong way from the start. Even if your blockchain repository is verifiably write-once, which it isn’t, it only records the data sent to it via your app and servers. Voting cannot rely on apps and servers, no matter how allegedly secure they are claimed to be. It’s nice that you generate paper ballots for a post-election audit, but since we should not and cannot ever trust voting servers and software, and therefore will need to do a post-election paper ballot count every time — how about we skip the man-in-the-middle, and all of your software, and go straight to that part?
But Russell brings up the very valid point that because software people are so fixated on adversaries, on hackers and not being hacked, their definition of “security” is often restricted to breaches and exploits and vulnerabilities, rather than systemic flaws, or sloppy development techniques, which hurt users’ security even if no external hacker is involved. In fairness, over the last few years the infosec community has been good at broadening its definition of “secure” beyond “external hacker resistant” … but it seems pretty apparent that much, much more work is needed.