Visibility of the source code is a side-show in electronic voting systems. Even if the source code is published, there is no way to be sure that that is the code that is running on the hardware, or to be certain that the hardware itself has not been tampered with. Votes need to be printed out on paper, verified by the voter, and counted by hand.<p>Still, when we had the source code for the Irish system (now abandoned due to our efforts) analyzed by a commission, it was found it had actual counting errors.<p><a href="http://www.stdlib.net/~colmmacc/www.cev.ie/htm/report/part4_2.htm" rel="nofollow">http://www.stdlib.net/~colmmacc/www.cev.ie/htm/report/part4_...</a><p>Amazing!
Professor Alex Halderman from Michigan has performed a few studies on Electronic Voting and Electronic Voting Machines, and essentially has proven that it is insecure. At one point, he hacked an American EVM to play the Michigan Fight song on every submission. You can read a few of his papers here: [1][2]<p>The challenge of creating anonymous and secure voting systems is still an area of constant research, and I do not believe that the Australian gov't has solved these problems yet.<p>Should we view the source? If we know it's insecure because it's basically unbelievable to think that otherwise, what good will seeing the code do? The fact that it is not being shown basically confirms the insecurity (if it was truly secure, we'd be able to see it without having a negative effect on the system). It seems the right thing to do is to fight this method of voting until EVMs are more secure, but maybe we should hedge our bets. Maybe we're going to be stuck with these EVMs in the interim, and we should avoid leaking the source to prevent people who have difficulty viewing the source.<p>[1] <a href="https://jhalderm.com/pub/papers/evm-ccs10.pdf" rel="nofollow">https://jhalderm.com/pub/papers/evm-ccs10.pdf</a>
[2] <a href="https://jhalderm.com/pub/papers/voting-wecsr11.pdf" rel="nofollow">https://jhalderm.com/pub/papers/voting-wecsr11.pdf</a>
As suggested, releasing the raw data as input would be better than the source code anyway. The raw data should not have any 'trade secret' or 'hack vulnerability'.<p>Vote for it on data.gov.au <a href="https://datagovau.ideascale.com/a/dtd/AEC-Raw-voting-data/42018-26233" rel="nofollow">https://datagovau.ideascale.com/a/dtd/AEC-Raw-voting-data/42...</a>
The algorithm used is fairly complicated, being both preferential and proportional. (The lower house is preferential but not proportional).<p>Here is a nifty visualization of the senate vote flows in NSW:
<a href="http://www.grwpub.info/senate/nsw.svg" rel="nofollow">http://www.grwpub.info/senate/nsw.svg</a>.<p>Essentially you need a certain number of votes to cross the line and win a seat. After winning the seat, those votes are subtracted from the party. Eventually when no parties have enough votes, the lowest voted party is eliminated and its votes are redistributed by preference.
If releasing the code is an issue, how about a compromise instead? How about releasing the code to a handful of independent third party firms and academics to determine for themselves if the code is safe. Does the AEC have an audit process in place where the code is checked and is there a testing environment of which the code is strongly tested for issues?<p>Given the undeniable complexity of such an algorithm, it would take more than a single audit to verify that it is secure. I don't doubt there is something up in the process somewhere, when it comes to vote redistribution I believe if not done correctly and properly tested, there could be some issues in that part alone.<p>Or better yet, release the data and allow academics from multiple institutions to independently run their own counts and then see if the results match up with that of the AEC's. I think that could be another way without releasing the code and verifying the results are accurate.
Honestly, the only way to prevent election rigging is to associate each vote with a key, make the key-vote-district database public and give each voter a copy of their vote keys.<p>If each vote is verifiable to the voter and the whole database is public, then we can have independent analysis done on the votes and no vote rigging is possible, except for creating additional fake keys.<p>And we can fix that problem simply by making the keys associated with a voter registration, which requires an ID. Same way we do now. Granted, that's still limited by the issues with paper ballots.
I propose someone sponsors a bill whereby any voting software used to count votes by the public must be open sourced and have several signatures (md5, sha1, etc.) which each voting center must verify before deploying it.<p>The voting centers would just have generic computers (perhaps with special peripherals for voting) which would load the software from a file and they could verify the signature of the file. There could be software that does this automatically. Such as the Apple app store.<p>That way, if any data centers detect an anomalous signature, they'd report it and it would raise a stink.<p>This is similar to the Apple App store except instead of Apple owning the ecosystem it would be their government. There are even better ways without all this crap -- either use an existing App Store from Google or Apple (or all) or have a browser extension and distributed app store from a distributed social app platform ;-)
If you want to help solve this please contribute to @mjec's campaign to raise money for representation by a barrister at the AAT appeal <a href="http://www.pozible.com/project/183015" rel="nofollow">http://www.pozible.com/project/183015</a>
I've always though the Hare Clark system is intrinsically I democratic (even though it produces reasonable results) because no one seems to understand it (certainly the people who claim to can't explain it). It's also non deterministic -- the outcome can change hassle on the order in which votes are counted (although the impact will be very small in all probability)