| > Currently, voter privacy is absolute in the US and does not depend | > even on the will of the courts. For example, there is no way for a | > judge to assure that a voter under oath is telling the truth about how | > they voted, or not. This effectively protects the secrecy of the ballot | > and prevents coercion and intimidation in all cases. | > | > | I'd pretty much dropped this topic after it became clear that Mr. Leichter's | only response to the problems that people pointed out in VoteHere's | scheme (in particular, its vulnerability to vote coercion, and lack of | recountability) was to attempt to redefine them as non-problems. I did nothing of the sort. With respect to voter coercion, I did raise the question of how absolute a value it was. Since mathematics tends to provide clearcut yes/no answers, we tend to insist on them in the real world, too - but the real world is rarely so simple. I also pointed out that voter coercion could be dealt with within VoteHere's framework by trading it off against the vote verifiability which is the new feature they bring to the table (by only giving some fraction of voters a receipt). I didn't mention recountability. VoteHere's method is equivalent to everyone else's here: Keep unalterable logs of data "as close to the vote as possible". But.... | However, since the topic has arisen again..... | | Ed's got a very good point. I always prefer security which relies for | its integrity on the laws of nature, rather than on people behaving | with integrity. This basically doesn't exist in systems today. Consider paper ballots: How do you guarantee that the ballots are adequately shuffled? If they aren't, anyone keeping track of the order that voters cast ballots might be able to come up with a reasonably accurate assignment of ballots to voters. This problem applies to many related systems. Consider the "paper under glass" proposals for recounting: The "obvious" way to do that is is to print onto a roll of paper and just wind it up on a roll after printing. But that's really bad, because it *guarantees* the ordering. Are those calling for such systems ensuring that the vendors who provide them actually cut apart the individual records? Even if they do that, how are they guaranteeing an adequate shuffle of those records? Just dropping them into a big box is terrible; certainly, those who vote very early or very late get very little privacy. Interestingly enough, proper shuffling of the votes is very much a central concern of systems like VoteHere's! The only system that "by the laws of nature" avoids this kind of attack is the mechanical voting machine, which inherently only stores vote totals, not individual votes. But these are big, complicated machines. Why should you trust that the totals are kept correctly? How could you check? How many people in the world have the competence to examine the mechanical details of such a device? How does that compare to the number of programmers who can examine C code? Is there really all that much of a difference between the complexity/verifiability of such a machine, and of a programmed box where *all* the code, including the compilers and other tools, is publically available? Yes, I know all about the attack in Dennis Ritchie's ACM paper. But this, too, can be defended against by checking the generated code - or pretty much prevented by using a compiler that was in existence before the software development began. In any case, these days, the mechanical systems could be compromised by what is an analogous attack (of going to a different level of abstraction): Sure, that *looks* like a solid brass 50-tooth gear, but maybe there's a tiny motor embedded inside that makes it act in a very non-classical fashion under radio control.... -- Jerry