Let’s get the fish within the barrel out of the best way. Voatz are a tech startup whose vivid thought was to disrupt democracy by having folks vote on their telephone, and retailer the votes on, you guessed it, a blockchain. Does this sound like a foul thought? Welp.
It turned out that they appeared awfully casual about basic principles of software security, akin to not hard-coding your AWS credentials. It turned out that their blockchain was an eight-node Hyperledger set up, i.e. one phenomenologically not particularly distinguishable from databases secured by passwords. They have been broadly and justly chastised for this stuff. But they aren’t what’s necessary.
To their credit score, their system is opt-in, and apparently generates real-time voter-verified paper ballots, the only most necessary factor about any voting system. But nonetheless. We must step again and ask a query right here: why are we attempting to vote through an app and collate election outcomes on any sort of centralized system in any respect? We don’t need to make voting extra environment friendly. Efficiency will not be the issue we try to resolve with elections. The inefficiency of paper ballots and their dealing with and collation and tabulation is a function, not a bug.
Just ask everybody at Def Con’s Vote Hacking Village, whose successes have been rampant this weekend, within the midst of the enmity of the National Association of Secretaries of State:
Voatz have been approaching the unsuitable drawback within the unsuitable approach from the beginning. Even in case your blockchain repository is verifiably write-once, which it isn’t, it solely information the info despatched to it through your app and servers. Voting can not depend on apps and servers, regardless of how allegedly safe they’re claimed to be. It’s good that you just generate paper ballots for a post-election audit, however since we must always not and can’t ever belief voting servers and software program, and due to this fact might want to do a post-election paper poll depend each time — how about we skip the man-in-the-middle, and all your software program, and go straight to that half?
The different level is dropped at us by XKCD, who responded to Voatz with this:
which in flip introduced this response from Facebook’s (soon-to-be-former) CISO Alex Stamos:
which in flip introduced this response from CFI and engineer Rob Russell, which lots of the best engineers I do know have been sharing throughout social media:
There are legitimate factors on all sides right here. Stamos is correct that almost all spheres, e.g. aviation, don’t must cope with the fixed menace of clever adversaries attacking the system in the identical approach that software program does (though as they occasions at SeaTac yesterday present us, they’re not at all devoid of such threats.)
But Russell brings up the very legitimate level that as a result of software program individuals are so fixated on adversaries, on hackers and never being hacked, their definition of “security” is usually restricted to breaches and exploits and vulnerabilities, relatively than systemic flaws, or sloppy improvement methods, which damage customers’ safety even when no exterior hacker is concerned. In equity, over the previous couple of years the infosec group has been good at broadening its definition of “secure” past “external hacker resistant” … however it appears fairly obvious that a lot, far more work is required.