They find a few really bad issues. IIRC, the Swiss Post is looking into improving it, with the consultation of real cryptographers, so we'll see how that goes!
You might be interested in some prior work on blockchain voting, it's a bit harder to get right than one might think, and actually introduces some problems [1,2].
To push this further, I was working on a research paper with Ron Rivest, Neha Narula (head of MIT's decentralized currency initiative), and Sunoo Park (a wonderful applied cryptographer) on whether blockchains in general could be helpful in casting and tallying.
> How confident are you that we could reach a well engineered and proofed electronic voting platform that also adheres to theoretical rules around vote security?
I don't think we can with the current commodity devices / ecosystem, even assuming that voting system software is well-written. Keeping electronic-only systems secure from nation-state level adversaries is hard.
To put this in short-hand: "We bank online, we buy all sorts of stuff online, why not vote?"
The biggest reason is that banking and other financial transactions have a very different threat model from voting.
In particular, voting requires a secret ballot. In addition to preventing an adversary from learning how you voted, a secret ballot requires you to be unable to prove how you voted, to prevent vote selling and coercion.
The honest answer is that I have no idea. In the version we reverse engineered, there's no proof of inclusion of any of the data in the blockchain in the client, and the receipt system was via a PDF. The vote selections (ballot?) are also never signed by the client.
It's also worth noting that, according to the ToB article, the backend blockchain is a permissioned hyperledger instance, which runs PBFT[1] rather than proof of work. PBFT is controllable with roughly 1/3 of the network, 100% of which has been controlled by the company.
3. Paper-backed ballots (which are the official record of the vote) that are physically voter-verified (as a requirement for the above)
4. Paper ballots are anonymized after submission, so as to avoid coercion and vote selling
5. Usability improvements
An app may be a solution to some of #5 above, e.g. as a ballot marking device at the polls, but in order to be secure it should absolutely have #1 and #2. FWIW, voting.works will likely support these.
The solution to long lines and timing is a complicated policy issue, which may not be solvable with technology.
Sure, though, to be pedantic, a common example of moral hazard is the increased likelihood of driving recklessly in the presence of mandatory seat belts. See https://web.stanford.edu/~leinav/pubs/RESTAT2003.pdf
>"Insured" can be interpreted very broadly; moral hazard is whenever the negative outcomes of a risky decision are directed away from oneself.
Nope! That's called an externality. A moral hazard is a type of externality, but is very focused on a particular set of instances in the definition I provided.
A moral hazard happens when an entity is somehow insured against something (e.g. health insurance), so is rationally more likely to behave in some "bad" way (e.g. driving recklessly).
I'm not seeing how this a moral hazard, do you just mean "immoral"?
Colorado successfully performed an RLA, and didn't have to recount every ballot. If you really want to read more, Free and Fair (IIRC, the same group bidding on the DARPA grant) has open source software and instructions on how to perform RLAs: https://github.com/FreeAndFair/ColoradoRLA
This is absolute hogwash, there are other methods than a full hand recount if you have a paper trail, some of which only require counting a small number of the ballots by hand.
The best example of this is a Risk Limiting Audit (RLA). You only have to re-count a smaller number of ballots until the overwhelming probability is that the vote is confirmed, or that the vote is rejected. Depending on the disparity between the ballot options, this count can actually be very small.
What's the plan for pairing based curves now that the Extended Tower Number Field Sieve has made BN256 unusable for many applications[1]? Do you plan on integrating BLS curves any time soon?