As a software developer at Jaume I University, Spain, I was asked from one of my colleagues to perform a technical review over one of the tools being developed at their lab. I've been following 'eSurvey electronic voting and surveillance' project from its beginning and, from a personal point of view, I belive that it's a great and innovative effort to develop an electronic voting system focused on simplicity of use and on granting user's anonimity over non-secure networks. That was evident since they decided to distribute their client on Javascript (deprecating a previous implementation in Java), but that brought some objections to my mind: Its great that the voter doesn't need to perform other action than opening an URL to vote, but how can you assure he is not being cheated by linking to a fraudulent client (or even sending a plain vote). Since voters are not expected to be expert code auditors, they needed some sollution capable of assuring client code integrity. The answer they found was developing a Firefox addon. As they pointed out, the client could be easily distributed and installed, integrity could be achieved by signing the addon, the original client could be included without any changes and, finally, a deeper access level to the navigator would enable them to add some code supplantation protection.
As foretold, I started my review by downloading the addon. Since it was allocated in their server, Firefox difficulted this step, asking for my confirmation several times. It doesn't happen on mozilla downloaded addons. When I reported my conclussions, I was told that the purpose of this review was to get the addon allowed for public download.
After installation, I was told to go to this site http://proyectostic.uji.es/pr/eSurvey/, in order to test the toolbar. Right on page load, a huge toolbar appeared on top of my browser window. It was a bit annoying to have all my toolbars and menus scrolled down by the new bar, so I asked the purpose of such decission. It seems that any other placement (floating window, any other position toolbar) would be easily imitated by remotely loaded xul, rendering it useless since any attacker could overlay the trustworthy client. It had to be shown over location bar because it's the only bar that cannot be hidden, so no externasl xul can be drawn on top of it (but it can be done below it). Bar layout seems quite simple: Project logo on the left, linking with project's main page, inviting you to learn security warranties provided by the voting client; then a logging textarea and a huge button, showing colored messages telling the state of the process and, at some point, activating and inviting you to participate in the polling. The page I had loaded contained a form with a sample survey so, I assumed it wanted me to report my opinion by clicking on my preferred options. Finally, I clicked on the huge button which started the survey sending. As a vague description, surveys are locked inside a onion package and sent into a latency-controlled-network where every layer is cyphered with a node's public key. Every layer contains info about which is the next node and how many time has to wait until sent there. This allows the survey to travel randomly around the network, rendering it untraceable to its origin unless every node administrator conspired (an unlikely scenario since nodes are located on distant and not related institutions). The survey is finally served to its recipient who will never know the origin, even if it was sent from a private computer anywhere. Votes are additionaly ciphered with Ballot box's public key, assuring it won't be open until recount time. When sending was done, a yellow sign instructed me to close the tab/window or visit another URL to hide the toolbar so, that's what I did. I also noticed an entry on the Browser's Tool menu which would activate/deactivate the toolbar on presence of a survey page (and do nothing on its absence). I asked about that feature and it seems that surveys can be instructed not to automatically launch the toolbar, but a voter must be able to force its use anytime.
After this initial test, I wanted to play harder on the toolbar. ¿What would happen if I opened several surveys on tabs?, It would be confusing to know which tab is currently processing the toolbar, but they keep control of how many surveys are opened in a window and they just let the first one to activate. After closing it and reloading the second survey would keep blocking until any other survey is closed. Opening different surveys on different windows wouldn't be a problem but to my surprise it didn't work. They told me this limitation was intentional, to avoid a more complex treatment of shared memory. I've repeated this tests randomly over several different test elections with good results.
I've been informed by the dean's office that last week, this application was used to perform a real election at this college's computer science department, becoming an absolute success, without any registered incidences or failures. This evidence makes me reach the conclussion that it's a well developed and strong application that needs to be easily distributable to all its potential users which, eventhough still are limited to one university, could grow in a near future.