You turn your back to start packing and something happens!
Essentially it gives you the right to look at the source code for 60 days and that's it. You can't really use the source for anything useful and more importantly it's referred to everywhere as a 'reference source implementation'. In other words the code could be completely unrelated to what is on the machines using VoteHere's VHTi system.
Let's be fair, VoteHere have taken a brave step and released this to the world. Of course they're hoping to get some good PR out of this and try to regain some attention amidst the controversy and competition from people like the Open Voting Consortium (more on them when I get back from Poland).
This download does offer insight into the design of the VHTi system and that's no bad thing. This is much more than any other supplier has done so far. And they've done it pretty much willingly – of course they need business but they don't have a gun to their head in the form of legislation or a specific negative story. Opening up the system's design to scrutiny is an important step.
Jim Adler, the VoteHere CEO, is a smart guy… but what makes him think that anybody is going to delete the files after the 60 days of the license has expired? There's no realistic way for VoteHere to check compliance (even if they do take your email address on download). It seems like they want to have their cake and eat it – if you're going to put your code on your website you have to let go of it, not try to keep the leash on. 60 days is just silly, they'd have looked a lot better with some kind of standard non-time limited license.
The system is based on patented ideas anyway (software patents are a bad thing but we know that, move along now) so, within the US at least, they're pretty much protected for the moment, license or no license.
But, reference implementation or not, there's absolutely no guarantee that this design or source is going to go anywhere near an e-voting machine.
I'm supposed to be packing but here's one problem I found in a PDF included in the download package:
As currently implemented, a very small number of BSNs may receive the same VoteVerificationCode for more than one BallotAnswer assigned to the same BallotQuestion. If these BSNs are used, it is possible that the voters VoteReceipt will be ambiguous. Though this may appear to be a problem, the event probability is small enough that extremely high confidence can still be achieved via the protocol. A simple remedy would be for voters who receive colliding BSNs to spoil the BSN and ask for another. Subsequent versions of the VHTi library will implement VoteVerificationCode generation so as to completely eliminate collisions within the same BallotQuestion.
Let me explain, quickly as my suitcase isn't done! The VHTi system works by showing the voter a number for the candidate they selected. So say I voted for Ronald McDonald as President on a kiosk then the screen would show his name and a number, 32 for this example. Then I get a printed receipt with the contest and number: President 32 So I can go home and check on a website by entering some code on the receipt which anonymously identifies me. The website should then also show: President 32 Each voter is given a different set of numbers for their choices. So two people voting for Ronald should have different numbers. Only I know that 32 is Ronald McDonald so the receipt can't be used for coercion or vote selling. (However there's no guarantee that because it shows 32 on the website that Ronald McDonald is who gets the vote in the system – I'm not keen on this system but now isn't the time to pick at it).
So what does VoteVerificationCodes Collisions mean? It means that in some cases the choices for a contest could all have the same number. So: President of Country – Ronald McDonald (32) – Humpty Dumpty (88) – Mickey Mouse (91) Is what the ballot could be for someone. But with the problem noted the ballot would be: President of Country – Ronald McDonald (32) – Humpty Dumpty (32) – Mickey Mouse (32) Thus seeing a 32 on the verification website won't mean much. If such a collision doesn't occur often then VoteHere are right, statistically the system (if it works as advertised) should still have enough voters checking to prevent large-scale fraud. But that's not the point, some voters will have been knowingly denied the right to verify that their vote was counted as they intended. This isn't a good bug to have, it's plain ugly.
I'm off to pack now, really.