1. Copy what your bank does.

For crying out loud, this is a solved problem! Banks deal with online funds all the time. When was the last time any e-banking solution from a major bank was hacked?

There are some major differences between banks and voting.

1) Bank security relies on the ability to undo and otherwise correct earlier mistakes, which requires a system with no anonimity.

2) An ATM going down is bad for business, but the customer will go to another one or suffer the wait. OTOH, American voters demand the vote results before going to bed.

3) The bank's system are used daily. Banks had a long time to learn from past mistakes. Voting machines are only used a few times a year. This also affects reliability. Electronic voting systems can't be load tested before the election.

4) The load is much greater for the voting system. This may not affect security, but I figured it would be worth mentioning.

The bank's system are used daily. Banks had a long time to learn from past mistakes. Voting machines are only used a few times a year. This also affects reliability. Electronic voting systems can't be load tested before the election.

This is why I would recommend that the bank's systems be used as a base. They've been battle-tested. Basically, the question is one of "How can we rebuild the wheel?", which is stupid. How many times have we said "Why are you rebuilding XYZ when it's already on CPAN!" You may not like your bank's website, but it works, and that's the point.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Happens all the time, depending on what you mean by "hacked". But online banking isn't the thing that's the most like voting -- ATMs are. How often do ATMs get hacked? All the time.

The huge issue is anonymity. Everything there is to record about ATMs gets recorded, to go back and look at later if it turns out there is a problem. You can't do that with voting. It's a secret ballot, meaning that it should be impossible to determine who voted for whom. At the same time, it should be the case that every vote is counted as the voter intended it to be counted, that no one should be able to vote more then once, that nobody should be able to pretend to be somebody else (living or dead) in order to vote as them, vote in elections that they are not qualified to vote in (by not residing in the proper area), and that nobody should be prevented from voting when they are qualified to do so, by not having ID (many people don't), by not speaking the language, by being blind, deaf, or both.

Clearly, these issues, especially uniquely identifing people without ID, is hard, and by focusing on the issues specificly of poorly impelemented electronic voting systems, people are ignoring the larger issues that these electronic voting systems are supposed to be solving.

---

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

You might do well to consider whether the answer to your question would be different, if the question were "When was the last time you heard about any e-banking...being hacked?"

The F(inance)I(nsurance)R(eal)E(state)industries still tend to deal with successful exploits by keeping them quiet and eating the losses

"I don't care who does the electing as long as I get to do the nominating" -- Boss Tweed.

Actually I find that the online access to US banks (well - the two I've used) is pretty dismal, and the protection relies too much on a few known data items (such as the SSN).

For comparison, the online access to my account here in Switzerland required that I fill in a request in writing, and then I received a special calculator and (by separate mail) a SIM card (with a PIN).

To access your account you have to know your contract number (NOT your account number), you need to know the PIN to your SIM card, enter six challenge digits that the online system generates into the calculator and enter the response that was generated on the calculator (which is alpha-numeric, BTW).

Pretty complicated, but the probability of getting hacked through simple password guessing is extremely small (absent other types of security problems in the code, of course).

Michael

I don't think you can make the comparison. I bet there are plenty of vulnerabilities in online banking systems. They don't get attacked, because if you're someone who wants to steal money electronically, the online system will probably get you fairly low returns (why get a few hundred bucks out of some soccer mom when you can snag a few dozen mutual funds?)

I therefore argue that online banking systems don't get attacked because they're secure. They don't get attacked because they have poor returns when you succeed.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

If I could attack a few dozen bank accounts, that would be a pretty decent return. What I'm saying is that banks have extremely high liability exposure. Therefore, copying them will, at the very least, be an excellent start to secure voting.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

For crying out loud, this is a solved problem! Banks deal with online funds all the time. When was the last time any e-banking solution from a major bank was hacked?

That isn't true. The banks have been "eating losses" caused by electronic theft, and keeping it unpublicized, in order to "maintain the faith of their clients". There have been quite a few stories written on this, typically someone (inside) electronically rips off an account, the victim starts to scream, and the bank just returns the money out of it's profits, and it's written up as a loss of some kind. When the security people finally track down the culprit, they are typically let off, if they promise to keep their mouth's shut.

So the banking system, only appears secure (albeit it is beyond me to hack it), but insiders can have a field day ripping them off. So think what insiders could do to rig elections? Even if they are traced down a year later, it is too late.

The only way is to have an open system, is where there is a paper trail, an audit number for each vote cast, redundant hard drives to store the data,( with them stored and transported separately), and freely inspected source code.

Perl would be perfect for this, because it is alot more understandable than C.

You have to face up to the fact that the people in power "want the ability to fix elections", it's the only way they will be able to control elections as the population of poor and underprivileged grows, to where the fat-cats would be voted down in fair elections. All the BS they put out, on the need for secret source code, is just pulling the wool over the eyes of the sheep.

---

I'm not really a human, but I play one on earth. flash japh

I read about inside jobs that relieve banks from their money on a regular bases. And that's the biggest treat e-voting systems face as well.

Would you trust an e-voting system written by a company which is (partially) owned by the Carlyle group? Do you know who wrote the e-voting system in your district? Do you trust them with your vote?

Forgot something: Diebold makes ATM machines.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

0. Copy what your casino does.

This is what Nevada did for their e-voting.

The problems are all (OK, how about mostly?) in the basic design philosophy the companies started with. Just be thankful that, under those conditions, they didn't use perl!

> this is not a Perl vs C issue

Sorry, I wasn't trying to make it one; but, the reference to a particular language made me think about how this would be accomplished in my favorite language. That's all.

My preferences aside, I think C isn't the greatest choice for this application, as it is more difficult to maintain secure, reliable code on a short time schedule. Remember that the voting machines must be very maintainable on short notice, because new voting laws sometimes get passed weeks before an election.

> The problems are all (OK, how about mostly?) in the basic design philosophy the companies started with. Just be thankful that, under those conditions, they didn't use perl!

On that point, I will agree. But, considering this is PerlMonks, a Meditation on writing a voting machine system in C or Java seems somewhat out-of-place. ;-)

radiantmatrix
require General::Disclaimer;
"Users are evil. All users are evil. Do not trust them. Perl specifically offers the -T switch because it knows users are evil." - japhy

Sorry if I seemed a little terse, rm. I've dabbled in both C and Perl, but have no idea which would be best for any given job.
ggg

I have to crack a smile when I hear "C" and "robust" in the same sentance.

There used to be a Free Software voting project called "GNU.FREE" around, but it seems to have stoped development.

But program and hardware stability isn't the biggest problem with electronic voting. Nor are any attacks from the outside. The biggest problem lies on the inside - the supplier of the voting machines (hardware and software). And don't think that making the software available gives you any security at all. Sidestepping the fact that 99% of the voting population won't have the skills to understand the program, do don't have the garantee that the program you have been given is the actual program that's running the voting machines - or the tally machines. There's no way to know that if you press the button for candidate A your vote is actually counted for candidate A, and only once.

I strongly suggest anyone who wants to participate in this thread first reads the past 5+ years of comp.risks.

if you believe you can write robust C programs, you shouldn't use Perl programs.

It's not that it's impossible to write robust C programs, but that it's difficult. Just by using Perl (or another higher-level language), you eliminate an entire class of possible attacks: buffer overflows.

Sidestepping the fact that 99% of the voting population won't have the skills to understand the program . . .

I don't have the mathmatical background to anaylize the security of any given cryptographic algorithm. I still want the algorithms to be made public as a way of keeping the orginaters honest.

. . . don't have the garantee that the program you have been given is the actual program that's running the voting machines.

And that's the ultimate problem.

There's no way to know that if you press the button for candidate A your vote is actually counted for candidate A, and only once.

There are many cryptographic voting systems, where the voter can verify that their vote went to the choice they want. However, most of them rely on a central, trusted authority. The decentralized ones I've seen are unscalable to more than a handful of people.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

> Well, if you believe you can write robust C programs

Just to be clear, that was a quote from a "news" reporter, not a personal opinion. But, for the record, you can write robust C programs.

> you shouldn't use Perl programs. After all, a Perl program can only be stable if perl is stable.

By that logic, you shouldn't use Perl for anything. Yes, you can write stable programs in C, but C takes more work to maintain and keep secure than Perl does.

> And perl is written in C.

Yes, I know. And that means that Larry Wall et al have already taken care of many potential issues and maintainance difficulties, leaving me with a language that is easier to maintain and secure. As I've said in another thread, nowhere did I try to start a "Perl is better than C" war. They're tools, and they have their uses.

Hearing the reporter mention voting machines written in "robust C" merely got me thinking about what could be done with some robust Perl. And, after all, this is PerlMonks, and suggesting that we all work to write a voting machine in C would be somewhat daft.

> And don't think that making the software available gives you any security at all. Sidestepping the fact that 99% of the voting population won't have the skills to understand the program, do don't have the garantee that the program you have been given is the actual program that's running the voting machines - or the tally machines.

Open code in voting machines isn't intended for review of 99% of the population. But, it would be nice if Universities and other non-partisan non-commercial organizations could review the code. More eyes tend to find more problems. Also, the fact that someone concerned about the security of the machine could analyze the code is, IMO, a good thing.

As far as guarantees of code version, at some point you have to trust election officials, who should be verifying the code signatures and MD5 sums on election-day startup. We might need to provide them with the training, but doing that isn't particularly hard, once you've been shown how.

> There's no way to know that if you press the button for candidate A your vote is actually counted for candidate A, and only once.

Sure there is. Visible paper reciepts:

• Touch your selection
• Confirm your list of votes
• A punched or printed ballot is popped into an enclosed, transparent box, clearly showing the choices you confirmed.
• Choose "cast these votes" or "destroy card and restart"
• If cast, the ballot card drops into a hopper.
• If "destroyed", the ballot card is stamped with red ink and shredded in view of the voter.
Then, there can be a reliable hand-recount if there are problems. Better, in fact: if care is taken about the format of the printed/punched ballot cards, the cards can be read electronically and verified against the touch-screen count as a "first pass" to help determine if a hand-count is required.
radiantmatrix
require General::Disclaimer;
"Users are evil. All users are evil. Do not trust them. Perl specifically offers the -T switch because it knows users are evil." - japhy

I'm a fan of the KISS principle. I'd make it drive a graphics engine (assuming I chose Perl for this task) that printed out a machine and human readable ballot. For example, a large X could be printed out in a fixed spot beside one of the candidate's names.

Next, the ballot would be passed through a verifier machine, to be sure that it can be electronically read. If it cannot, it must be shredded, and a new ballot must be printed, to avoid a spoiled ballot.

A large man with a dangerous object in his hands would prevent anyone from putting more than one ballot into the ballot box.

The machine readable ballots would then be quickly counted (say with a big sheet feeder passed through an OCR style process), and then verified by one or more hand counts.

The hardware would be the hard part: ensuring that the printers printed, the scanners scanned, etc. In general, hardware is more reliable than software, so I'd rather put my trust in that. As a voter, I can't tell if the software in the blinking box is working, but I know an X when I see one.

This seems like the most robust way I can think of to:

(a) provide ballot validation, as an improvement over paper ballots. Since each ballot is validated before it is cast, there won't be debates over whether a circled box counts as a X in the box, and so forth.

(b) provide a quick inital count, so that results can be announced quickly (people want to know "who won").

(c) provide a human verifyable recount.

(d) Satisfy the requested conditions

Security:People can't really tamper with the system, because all it does it print ballots. Voters can tell instantly if it breaks, because then the ballot they print isn't the one they wanted. If anyone tries, the large man gets up and hurts them.

Stable/Redundant A generator with power backup for the length of the election could keep the system running. The software is simple, and unlikely to fail catastrophically. If any system fails, it can be reset (one possible strike against Perl, since the right answer is an instant-on ROM image, IMHO). If an EMP pulse takes out the entire system, the cast votes remain in the ballot box, and the remainder of the ballots are cast by hand.

Accessible This is hard, but not impossible. Blind, deaf, and dumb people use computers. A soundproof booth with braille keys and a pair of headphones could assist a blind person. The booth would be transparent, so that no-one could sneak in behind the blind person, out of sight of the scrutineers. The large, dangerous man can also help with the physical security aspects.

The verifier machine would be especially useful for the handicapped, as a second confirmation that they did vote the way they had intended.

(e) Ensure trust in the system, by making it as simple and transparent as possible. Each person, regardless of role, should know as much as possible about the system.

As a voter, I know my vote went into the box. If I want, I can stand around, and make sure no one else is putting more than one vote in the box.

As a scrutineer, I know that nothing was taken out of the box until it was opened. I also know that the box was empty when the election started, and each voter put exactly one ballot in the box. This tends to suggest that the ballots in the box are the ballots that I saw the voters cast. I get to count them as many times as I want to ensure they add up.

While it's technically still possible to rig up a magic trick ballot box (say, with hollow sides that catch the real votes, while the planted votes remain inside the locked door on the front), it's hard to do, and careful examination of the box (say, with X-rays) will catch it.

Writing buggy software is very, very easy. Proving that software is correct is very,very hard. Using software correctly in elections means using as little of it as possible, IMHO. --
Ytrew Q. Uiop

Next, the ballot would be passed through a verifier machine, to be sure that it can be electronically read. If it cannot, it must be shredded, and a new ballot must be printed, to avoid a spoiled ballot.

Egads, no. The last thing you want in a polling place is a shredder. You want a big envelope with big black letters saying SPOILED BALLOTS, and an election judge should supervise the voter as they put their spoiled ballot into it; then the voter is given a new one.

At least that's how it worked last night, when I was an election judge in Hennepin County, MN.

Egads, no. The last thing you want in a polling place is a shredder. You want a big envelope with big black letters saying SPOILED BALLOTS, and an election judge should supervise the voter as they put their spoiled ballot into it; then the voter is given a new one.

At least that's how it worked last night, when I was an election judge in Hennepin County, MN.

You must still somehow ensure that no one ever looks in that envelope. Otherwise, it may be possible to determine how someone voted from the spoiled ballots. For example, suppose that there are only 3 spoiled ballots, all of which are for one candidate. Now, everyone who saw those three people put their ballot in the envelope knows how they voted. This violates the right to an anonymous vote.

To prevent this, the invalid ballots need to be destroyed somehow. If they aren't, someone might read them. You could wait until the end of the election, then shred or burn the envelope, but it still needs to be done. However, if the voter is allowed to shred his own invalid ballot, then he doesn't have to hope that no one will look in the envelope when he leaves the room.

The main requirements must be that: (a) no invalid ballot can ever be viewed by anyone other than the voter, and (b) no invalid ballot gets cast as valid.

I'm again relying on the large, dangerous men to prevent elections tampering, including any deliberate shredding of valid ballots. That should be obvious: they're in a separate box, far from the shredding machine.

It occurs to me that a more dangerous issue with all computer/electronic based systems is the risk of a hidden logging system. It would be easy to sneak in a section of code (or a custom set of electronics) that only activated on election day. It could secretly record that a vote took place at a given time, and who was voted for. It could be hidden as part of the debugging code, for example.

With the timing information in hand, you'ld then just need to keep track of what person voted at which time. An observer at the polls with a watch and notepad could do that part. By cross referencing the time with the person, you now know how everyone voted.

--
Ytrew

I might use Perl as part of the document preparation process, so that when voters fill out their paper ballots, their choices are clear.

Electronic voting is not necessary, and not a good solution to the perceived "problems" with the current voting process.

I heard a pundit say that these machines were "written in the robust C language";

Who was this "pundit" and did they say it with a straight face? Like that's some guarantee or something?! That's like saying 'the script for "Gigli" was written in the robust English language' ... so what, it still sucked.

"Robust" is one of those touchy-feely marketing words ... usually meaningless.

It's something I heard on the radio, and I didn't catch the name of the speaker. It was, however, pretty clear that he didn't know what he was talking about, and just repeating press releases.

An amusing comment I heard during his yammering was "these machines use encryption, eliminating the possiblity that they can be tampered with". ;-) In other words, he said a number of things that were patently false, some which were misleading, and others -- like the "C" comment -- which were correct but had nothing to do with the subject at hand!

radiantmatrix
require General::Disclaimer;
"Users are evil. All users are evil. Do not trust them. Perl specifically offers the -T switch because it knows users are evil." - japhy

IMHO one of the problems is not just the ballot counting, but the voter registration - I'm still amazed that the US does'nt have an upto date registry over the inhabitants their whereabouts etc. so a complete list of voters easily (and without the almost neverending legal squabbles) can be produced.

But none of this refers to perl in any way.

Update: Just remembered! I think that it's in Beyond Fear. The covernotes include: Will computerized voting machines make election results more accurate?

There is an excellent article Guru Lincoln D Stein on this in TPJ issue #20: Secure Internet Voting with Perl written after the 2000 Elections.

So, Monks, how would you use Perl in a voting system?

I'd probably use it to implement some of the protocols described in Section 6.1 of Applied Cryptography.