Why does this keep coming up? What is the compelling argument against paper ballots? There is no need for results to be known immediately, so how does making voting an exercise done by computers make anything better, particularly when computers are much more vulnerable to remote interference?
The swiss Post organized recently a public review (with awards to identify bugs - see another older thread on HN) for the software that they'll try to launch.
On one hand the swiss Post's solution would allow me to actively check if my vote was part of the total, which I think is absolutely fantastic.
On the other hand I did access the source repository of the new potential voting system but I didn't even start digging into it as soon as I saw that it was written in Java.
I thought that such a software, which is the foundation to the future of a nation (voting system), would have as its foundation 1) a language that leaves very little room for technical and functional bugs (e.g. something used in the aerospace industry?), 2) would be structured using an extremely well-known-for-its-reliability workflow-engine and 3) was submitted to testing covering basically ALL possible combinations at ALL levels (not just e.g. "10000 cycles of randomness" but all possible input-values, for all layers).
When I saw that it was written in Java (nothing against Java - same thing for e.g. C/C++) I immediately gave up because, even if that SW is made to be absolutely unhackable >>nowSummarized: I'd like such a system, but I would need it to implemented in an extremely strict way that is able to survive times of low budgets and/or bad employees and/or bad management and/or of course corruption, which is when coincidentally a stable solution would be needed the most.
I usually (have to) choose between dark- or light-grey when I vote, but in this case, to replace the current system, it's one of the rare occasions for which I would need a "pure white" solution :)