The Irish STV implementation also has to redistribute so called "surplus" votes.

Since it features multiple candidate constituencies the amount of votes required to get elected is not a simple majority but a quota defined by the Droop formula (Total number of valid ballots/(Total number of candidates +1))+1. Ballots for candidates who exceed the quota have a surplus and that surplus gets redistributed according to the next preference on the ballot. The exact mechanism for choosing the actual votes that comprise the surplus amount is random and those randomly selected votes are then transferred as full votes to the next preference candidate. So when a candidate has 10000 votes with a quota of 8500, 1500 ballots are chosen at random and the preferences in those ballots are used to transfer them to the remaining candidates in play. For situations where a candidate gets a surplus on a second count (ie including transferred preferences from an eliminated candidate or from surplus votes from an earlier elected candidate) only the ballots transferred at the last stage are used when selecting the surplus votes to be transferred.

These shortcuts were introduced to speed up manual paper counts but they meant that the task of comparing an electronic count to a paper Voter Verified Audit Trail (VVAT) presents an interesting problem. In order to be able to fully and accurately validate the electronic count the VVAT records would have to be able to be tied exactly to the sequence of the electronic votes (so that each electronic record could be tied to each paper record and the random selections for surplus redistributions could be matched up). One solution to this would be to remove the shortcuts for electronic voting but that would have meant moving to e-Voting entirely as they could not use two different counting methods in different constituencies. So they had to implement an e-Voting STV counting mechanism that followed the same rules as a paper count would. Not hard to do but this then led to a further issue for those of us arguing for a voter verified audit trail for any e-voting system.

One of the Irish Government's least silly arguments against any VVAT for e-Voting was that such a capability might be compromised and could result in someone figuring out exactly how (some) individual voters had voted. Since the Irish constitution explicitly specifies that parliamentary voting must be secret this was something they were very much afraid of - it's notable that since the constitution does not explicitly require counting votes to be accurate (it only implies this) they were less concerned about that. Anyway that's how it seemed to me when I met them about the issue - they didn't say it as bluntly as that but they were terrified about the potential secrecy problems but only worried about the potential for "small" errors.

The real problems with the Irish e-Voting debacle had very little to do with the complexities of an STV count - they were the same as they were\are in most other counties though. The machines in question were provided by private companies, closed and not adequately tested by properly independent security professionals, the vote tabulation software was also closed, similarly unavailable for inspection by independent specialists and most worryingly it was never available any significant period of time ahead of any given election as it had to be rewritten for each count. The lack of a voter verified paper audit capability (which could have been implemented safely despite the concerns described above) meant that the systems could be attacked\compromised\fail in ways that could materially affect an election without being detected. In the end though few of those problems led to the current Government's decision to abandon the problem, they finally got fed up with the political and financial costs associated with fighting to keep the project alive and they gave up. I'm pretty sure that many of the Government Ministers and civil servants involved still think that the Nedap\Powervote e-Voting system was perfectly fine.

Whoa. I think I can help here...I speak a little PHB:

Thanks AC. Glad to see you went to the comedy school of IT.

"I manage the people who run the email servers for my company. I have a degree in business; I am skilled at synergizing my big-picture ideas on a going-forward basis."

No business degree, sorry. Just an engineer and I manage nobody, I design and build the systems. i'm glad that you think I'm qualified to run the whole show, I'll make sure to remember that at my next review.

"We need secure logins, but we don't trust our users."

Well no I don't trust my users, and neither does any other systems admin but that's not the point. Building a secure and usable access control mechanism for mobile devices is hard. Would you be happy if you hired a systems admin who accepted that a username and password alone was sufficient for remote access into your systems? If so then its time you reviewed your risk posture - for my part I like to use RSA-Keys, Certs and one time tokens for that sort of thing. Passwords do not cut it, sorry.

"We did not cover secure IMAP in my MIS classes."

Actually true but only because I never attended any MIS classes. Anyway I was talking about authentication protocols and not mail protocols here so I don't see your point. Mutually authenticated secure IMAP would be good if it turns out to be possible to figure out a secure way to distribute certificates to the device but there is no indication that the iPhone will ship with a good enough certificate enroller and as a closed system writing our own is not an option.

"Encrypted, password-based authentication is too simple to possibly guarantee my job."

100% true. I'd be fired if I suggested it and I'd expect no less. Seriously, passwords don't cut it for authentication over untrusted links in this day and age, if you haven't realized that yet then I suggest you start thinking about why good SSH implementations don't use them.