Princeton Undergraduate Student Government

It's been a long time since the last blog post, but that's not because there haven't been any updates.  In fact, it has been quite the opposite; we've been so busy making progress that I haven't been able to write about it.  But I finally found the time over break to share the good news!

First, Helios succeeded brilliantly in the class of 2013 elections.  In fact, we had to run Helios an extra time because of an human error on the elections manager's part, so we got one extra demonstration of Helios.  Taking what we learned from this election and other improvements we didn't have time to make by that election, we're now making the final changes to Helios before this next election.

Even though the technology has come a long way, the place where we are most vulnerable to having problems, elections managers and protocol, still hadn't been improved.  But two weeks ago I jumped on the opportunity and re-authored the Candidate Handbook and began a draft of the comprehensive Administrator Handbook to give the elections managers direction on certain specific protocol items and how to avoid common mistakes.  We rushed to get the former piece ready in time for the election, but the latter will remain a work in progress that we will add to based on what we learn from this election.

Click here to download the November 15th Senate Presentation

The Technology: Helios

Maximum Speed Under Full Load

The system we used before Helios used to buckle under the load of voters that occurred immediately after the USG President sent the email announcing the beginning of voting.  Ironically, though, Helios actually gets faster under full load.  The system sits on the Google App Engine platform, meaning Helios runs on Google's servers.  Google designed the servers to deliver performance relative to usage: when few voters are using Helios, Google diverts resources elsewhere.  But when many voters are using Helios, the Google infrastructure responds by diverting more resources to Helios.  As a result, everything runs more quickly exactly when we need it most: under full load.

Helios Decryption Trustees

The part of Helios most likely to cause problems for us is the trustees part.  It's certainly not a problem, but it is a concern I have.  Helios divides the ability to decrypt the tally among a number of "trustees."  We have chosen to have two trustees: the chief elections manager and Dean Dunne.  Before voting takes place, the trustees generate "keys" which are essentially very long passwords.  These keys are then required to decrypt the tally after voting has taken place.  This means that no single person, not even a trustee, can obtain vote counts until all of the keys have been inputted.  However, here's the concern: if one of the trustees loses his key, it is impossible to determine the results of the election.

This may sound bad, but think about it this way: there is no back door.  Problems could arise if there existed some back door that allowed someone to circumvent the trustees and obtain the results.  So it is absolutely critical that the trustees do not lose their keys.  In the three ballots for the class of 2013 elections, however, we had no problems with this.  But that was in part because I was fanatical about this issue and guided Dean Dunne and Addie through the process.  Carelessness in future elections, however, could easily cause this to be a problem.  Aside from having competent elections managers to prevent such a problem from arising, the administrator handbook we're developing will also outline very explicitly and clearly how best to go about generating and storing trustee keys to avoid the potential for problems.

Ease of Use and Lack of Problems

Although there was the extremely public flub where the elections manager misspelled email addresses and names, the launch of Helios went off without a hitch.  It is unfortunate that this human error overshadowed what was the best possible launch of a new voting system I could have hoped for.  There were no catastrophes, no failures, no glitches, and just one complaint.  The only complaint I received was from a student who had chosen not to install (or to uninstall) Java on his computer.  However, even he was still able to vote by using another computer -- nearly all computers do have the software required to run Helios.  Aside from that, Helios did it's job: it provided a transparent, secure, reliable way for voters to cast their ballots, and it didn't get in the way.

All in all, I was thrilled with the launch.  We even had to use Helios three times instead of the expected two, and during all three votes Helios performed dependably and flawlessly.  The documentation I created may have helped a few voters, but our data shows that most voters were able to use Helios without any instruction -- plain and simple.  Mission accomplished!  Sort of.  We still have some more tweaks we're in the process of making for the upcoming election, so we're not done yet.  But the first use of Helios definitely was promising.  I look forward to many more successful elections run using Helios.

Click here to go to the Helios Headquarters

Improvement: Anonymous Voter Aliases

As part of the auditability Helios offers, voters can go back to the Ballot Tracking Center at any time and match their NetID with the tracking number they received when voting to confirm that their ballot is being counted.  But we are concerned that there could be negative consequences to making these NetIDs public.  No personally identifiable information is made available at any time, but it does allow someone to determine whether or not a student voted.  There are a few problems this could cause, but I won't list them here.  Rather, I'll explain what we're doing about this.

Work is in progress on a modification that will assign to each voter a unique alias.  This alias, instead of the NetID, will appear in the Ballot Tracking Center.  This way there should no way to connect individuals to the records of the votes cast.  Upon successfully casting a vote, the voters will be emailed their unique alias and tracking number.  These two pieces of information will then enable the voters to go into the Ballot Tracking Center and check on their ballot at any time.

Improvement: Registrar Certification of Voter Eligibility

Until now, voter eligibility was checked against the public directory (LDAP) -- the same directory that suggests names in your email client and feeds data to http://search.princeton.edu.  However, this directory is only about 99% accurate.  In previous elections, we had difficulties where students who were eligible to vote were denied access to the ballot by the system because their information in this public directory was either innacurate or missing.  Students can request that their information not appear in the directory, and this would cause them to be unable to vote.  Also, students who are abroad may not have been eligible to vote because their status appears differently in the directory.

This is the way elections had been working since Princeton first started using online voting.  And for the 2013 election this past fall, we had to stick with that system because we didn't have the time or resources to do anything better.  However, we knew there was a better way: access the Registrar's database, the definitiive source of enrollment verification and voter eligibility for USG elections.  You may be able to trace back this issue through to the origins of our project; it has been an important one since the very beginning -- we had been discussing it since April at least.  But, as you can imagine, accessing that extremely sensitive information is not easy.  It requires approval from a variety of offices on campus, plus the technical pieces in place to facilitate the check.  But we're making it happen right now!

We've received all of the approvals we need, and the project to build the necessary technical components is well under way.  Everything is expected to be complete by the end of this week, just in time for this election.  If everything goes according to the schedule, the component will be in place for this election and Helios will be using the Registrar's database to verify voter eligibility.  I am especially thankful to Dave Herrington of OIT's Departmental Application Servies for his contributions to this particular component and the project as a whole.

The question of how "Registrar Certification" fits into Helios has remained in question until now.  You may recall that for the previous election system, the Registrar "certified" the election results before they were released.  To all intents and purposes, the extent of this certification was limited to logging in and clicking a button that ran a program to print the tallies.  The elections managers then used these tallies to announce the results.  Before I learned this, I naively though "certification" meant someone sat poring over every vote and checking eligibility.  That was not the case at all.

But with the new system, we have come much closer to what I originally imagined.  The primary differences are that this check will be made automatically via the Registrar's database and that it will take place before the vote is cast not while being tallied.  So when Helios gives us a tally, those results are certified by way of this mechanism.  The certification being made is that everyone who cast a vote on that ballot was allowed to do so by regulations.  Below is the list of students, confirmed by Jonathan R. LeBouef, Associate Registrar for Reporting and Institutional Research, who are explicitly eligible and ineligible to vote according to this new system:

Eligible to vote in USG Elections

• Regular undergraduates enrolled in courses
• Undergraduates enrolled in study abroad programs

Ineligible to vote in USG elections

• Undergraduate Visitors, i.e. students from other institutions who are currently enrolled in courses at Princeton as part of a formal exchange program
• Undergraduates currently enrolled in the Bridge Year program

Improvement: Approval Voting

Since the inception of this project, we've known about the problems inherent to using the method of Single Transferable Vote.  In brief, here's how we used to use STV:

1. Voters select a first and second choice candidate
2. Tally the voters first choice preferences
3. If not enough candidates receive the required number of votes to be elected, drop out the candidate receiving the lowest number of votes
4. For all voters who had selected the candidate that was just dropped out as their first choice, activate and count their second choice votes
5. Repeat steps 3 & 4 until enough candidates receive the required number of votes to be elected

The very fact that I had to give this explanation reveals one glaring weakness of STV: it is complicated.  Too complicated.  STV is complicated for voters to understand, and it poses a large technical problem to develop a system capable of carrying out the complicated calculations and transfers required.  Therefore it is not surprising that we've had so much trouble with and confusion surrounding elections with STV.  Our crimson brother to the north also seems to be having trouble with elections that use STV.

Let me go one step further to explain a scenario that demonstrates how the principles behind STV can actually result in an under-qualified candidate obtaining many votes.  It's not a perfect example (I invite you to poke holes in it), but the point being illustrated still holds.

For simplicity, imagine using STV in an election with three candidates vying for a single position (in this case with one position up for election, it is called Instant Runoff Voting, IRV, but that's mostly a nominal change that still demonstrates a problem for elections with multiple winners).

John and Jane are the two frontrunners -- they are highly qualified, but strongly polarizing.  Most people either like John or Jane, but not both.  There is also a third candidate, Dick, who few people like -- he is not as highly qualified as John or Jane and perceived as unlikely to win.

The STV ballot allows voters to select a first and second choice candidate.  For their first choice, most voters select either John or Jane according to their preference.  But, not wanting to give the other frontrunner an advantage over their favored candidate, they decide to "waste" their second choice on Dick.  After all, he is unlikely to win, so he will not pose a threat to the candidate the voters wants to win. When it comes time to tally the vote, John and Jane split the vote and everyone's second-choice votes end up getting transferred to Dick.  Dick ends up getting more votes after a transfer than John or Jane.

You see what I mean?  STV can get messy.

A fortunate coincidence was that it would be extremely difficult to implement the vote-transferring of STV using Helios, so it would be ideal to replace STV anyway.  In August, when I felt strongly that we should use Helios, Ben (the Harvard postdoc behind Helios) and I discussed this.  If we wanted to use Helios we had to either ask Ben to start working on it immediately, or we had to find an alternative by November.  Given all of the problems with STV in the past, we decided it would be best to start looking at other options and let STV go after what has proved to be a tense, unpredictable relationship.

Ben suggested that I contact Dr. Ron Rivest of MIT who researches matters such as these.  In my email exchange with Dr. Rivest, he suggested range voting or approval voting as worthy alternatives for our purposes.  He agreed that either of these choices would likely be better than STV.

Range voting is the type of voting used at the Olympics.  Voters can score each choice on a certain scale (at the Olympics, 1-10).  Then, the averages are taken and the choice with the highest average score is the winner.  One adaptation of this we had considered for our own use was a scale of -2 through +2 with integer resolution.  In essence, voters could add or subtract up to two "votes" ("points?") from each candidate's total -- the candidate with the highest total wins.  But the USG members I discussed this with did not like the "negative voting" aspect, so I suggested the alternative being 0 to 2.  A vote at level 0 means "no confidence," a vote at level 1 means "approve," and a vote at level 2 means "strongly approve."  The winner would be the candidate with the most "votes" upon adding up these scores.  Although this particular option remains my favorite choice because of the high degree of expressivity, it still didn't seem to gain traction among the senators who would ultimately need to approve this change.  However, a closely related cousin, approval voting, did gain traction in the senate, and offers most of the same benefits with even more simplicity

Approval voting (AV) is a very specific form of range voting where the range is between 0 and 1.  Like in the range voting example above, a vote at level 0 means "no confidence" and a vote at level 1 means "approve."  This can be represented on a ballot just as check boxes next to each candidate's name -- a check indicates a score of 1, and no check indicates a score of 0.  This form of voting gained the most traction in the senate and has a good deal of support in academic research.  If you'd like to turn over the same stones I did when I conducted my research, start at the Wikipedia article for Approval Voting and read the pages listed in the "Notes" and "External Links" section.  Also, look for research by Steven Brams and crawl the web for "Approval Voting."  I was pleased to find that organizations who should be "experts" in this field had chosen AV for their internal elections: American Statistical Association, Mathematical Association of America, Institute for Operations Research and the Management Sciences.

Once I had found enough research and practical evidence in support of AV and had determined that the senate was in agreement, we now had to make the necessary changes to replace STV with AV.   This meant modifying the campaign Rules and Regulations document and the USG Constitution (we would later find out that the CPUC charter also needed to be changed, but I'll discuss that later).  After having a meeting with the new elections managers, we determined the schedule for the election, and it became obvious that we did not have much time to make the necessary changes we needed -- the change would have to be made in time for the election, otherwise we would either have to use WebSurvey instead of Helios to use STV or use Helios and AV in blatant violation of the USG Constitution.  The process of amending the constitution via the senate requires a majority vote at two consecutive senate meetings, so I delivered the presentation at the first meeting on November 15th, and the motion to amend the constitution with the changes for AV passed unanimously (two abstentions, no opposed).  The second vote on November 22nd passed with the same outcome -- success!  We were ready to use AV and Helios for the December election!

But then a student brought it to our attention that the two documents we had just changed (the Election Rules and USG Constitution) were not the only documents that specified how to conduct elections for U-Councilors.  U-Councilors are elected to serve as members of the USG senate and the Council of the Princeton University Community (CPUC).  It turns out that the CPUC Charter also specifies that U-Council elections will be conducted via STV.  This means that until the CPUC Charter is amended, the USG Constitution and the CPUC Charter will be incongruous.  It's not too much of a concern, though, since the U-Council elections are not until the spring, and we have plenty of time to make the change by then.

You may be skeptical about approval voting, either because you don't know much about it or because the change happened so quickly.  But I can assure you that we've done the research and believe that the change to AV is advantageous.  That said, even among the experts there is still a great deal of disagreement, so I don't expect that everyone will agree with this choice.  You may very well conduct your own research and come to exactly the opposite conclusion as we have.  That doesn't mean that one person is completely right or wrong, just that there is no perfect solution.  We believe strongly that we have found a voting mechanism that is the best choice when taking into account a variety of theoretical and practical concerns.  If you feel strongly either way, though, I would love to hear your feedback via email.

The People: Candidates

The candidates have just as much responsibility for ensuring a smooth election as the elections managers do.  Candidates who are knowledgeable about the elections process can proactively help the elections managers do their job and also help catch mistakes before they blow up into huge problems.  Until now, there had been no document specifying information about elections -- everything was simply spread by word of mouth and institutional knowledge retention.  But I took the opportunity to change that by creating a Candidate Handbook, "The Definitive candidate guide for USG elections."  This document contains everything a candidate should need, from the description of the positions to the forms required for candidacy.

Improvement: Remastered as a public Google Doc

The only official document that exists for elections has been the Rules and Regulations Guide.  However, this document has become a Frankenstein document -- with tons of haphazard changes made by previous administrations.  The formatting was inconsistent and difficult to read, and the content was badly in need of revision.  So I got to work on completely remastering it as a public Google Doc.  I couldn't just upload the old Word doc and hope for the best -- I stared from scratch and pasted in individual sections by stripping the formatting.  In doing so, I was also able to identify and make changes to pieces of the regulations document that needed updating.  I was also able to format the document very carefully and cleanly.  And, since it is a Google Doc, it can be made public very easily.  The document is available right now at http://usg.princeton.edu/candidates

Click here to download the PDF version of the new Candidate Handbook
Click here to go to the Candidate Handbook as a Google Doc
Click here to download the old Rules and Regulations document.

Improvement: Rules and regulations section updated

Going through the process of copying the document section-by-section also enabled me to identify areas that needed to be changed because they were outdated, unclear, or inconsistent.  Some of these changes were as simple as updating terminology and adding clarity, but other changes such as the change of STV to AV were more complex.  In the end, though, I believe I was able to make some meaningful changes to this part of the handbook that will make elections run more smoothly and less confusingly.

Improvement: Candidate Guide

This is the newest and most important part of the Candidate Handbook devoted to giving candidates as much information about the elections as they may find helpful.  There are a few important parts.  Click here to jump to it in a new window.

The "Elections Overview" and "Typical Elections Cycle Schedule" both outline the three different elections that take place over the course of the year and a typical timeline.  I have created a four-week model that applies for all three elections.  The first week is the week with the open houses, the second week is the campaigning week, the third week is the first vote, and the fourth week is the run off vote.  The guide is fairly explicit and has been developed for the candidate's perspective; it gives a list of deadlines and the items that must be turned in at those times.

Another important section is the "Communications from Elections Managers" section.  It provides a list of emails that the elections managers will send to the candidates.  If the candidates are aware of what emails they should expect to receive, they would be able to determine early on if they aren't receiving the emails they should from the elections managers.  This will prevent a misspelled email address that the elections mangers have from causing a candidate to miss out on all of the important emails.  Hopefully the candidate will be able to catch on early and notice that he isn't receiving the emails that he should be, thereby causing him to contact the elections managers and get the issue sorted out.

The final sections discuss the different voting mechanisms in use, including run off voting and approval voting, and Helios.  Eventually I expect that students and candidates will become used to the unfamiliar characteristics of Helios that I have listed in this section.  But until then, I think this could help clear up some confusion.

Improvement: Forms

At the very end of the Candidate Handbook I have also recreated the two important forms that the candidates must complete and return to the elections mangers: the Candidate Registration Form and the Petition for USG Office.  I used previous versions of these forms as a basis, but recreated them from scratch in Google Docs in order to add clarity.

The People: Elections Managers

The most critical component of the elections process is the elections manager role.  Competent, dedicated, and well-informed elections managers can make the elections run smoothly.  But the reverse is also true, and only one of those three qualities I have listed needs to be missing for there to be problems.  The problem with elections is that simple flubs can quickly escalate to become huge catastrophes.  Take, for example, the Class of 2013 election that just took place.  The mispelling of one candidate's email address was enough to cause the vote for an entire office to be invalidated and require a revote.  Just a small mistake -- one finger to the wrong key -- and a revote is required.  These are tight tolerances!

Although there's not much that can be done about competency and dedication aside from selecting good people, information is something we can take into our own hands.  I'm frankly surprised and disappointed that there existed no document like the one that I just created.  Elections had been run by elections managers who were simply running elections based on what they felt should be happening.  There was no guide.  No manual.  Nothing.  Inevitably, this caused problems.  Realizing this, I started work on what I hope will become just such a guide: the USG Elections Administrator Handbook.

Click here to download the USG Elections: Administrator Handbook draft (11.29.09)

USG Elections: Administrator Handbook

The document is currently only a draft.  I've laid out the sections that will eventually be included.  There is so much that should be included in this document, but it will require more time to complete than the one day I spent working on this and the Candidate Handbook.  For now, you can refer to the table of contents to get a clearer picture of what the document will eventually include.  Here is a synopsis:

Roles and Responsibilities

This part includes a list of all of the people that are involved in the election process.  Here is the list I currently have:

• Chief Elections Manager
• Supporting Elections Managers
• Helios Trustees
• USG President
• USG Vice President (new to this article)
• USG Senate
• USG IT Chair
• Office of the Registrar
• Office of Information Technology

All of these people have some part in the elections process.  It's pretty amazing to realize just how complicated the elections process is.  It's  a shame that most people don't realize just how complicated elections are.  I would compare the complexity of elections to the mechanics of an airplane -- there are a wide variety of pieces and functions that all have to work together in harmony to succeed.  If one fails, sometimes the other parts can compensate.  But if too many pieces fail, then something bad happens.  Take, for example, the Class of 2013 revote that just took place.  The candidate whose name was mispelled on the ballot was also the candidate whose email address was misspelled.  He would have had the chance to check his name on the ballot (a safeguard), but because a second system also broke down (the email address), the problems compounded and caused the flub.

Within this section I plan to outline for each position as many pieces as are prudent.  For example, for the elections managers, I'm going to outline how they get appointed, what qualities they should have, and what responsibilities they have to carry out.

Schedule of Events

This is perhaps the most important part of the whole document, so this is the part I prioritized when developing it. The goal was to have a draft of the schedule ready for this election so that the elections managers could use it as a guide.  Because it is still a draft, this document is now definitive or authoritative just yet.  But it does have some good information they will be using.

First, I outline the four-week schedule.  I have formulated a four-week schedule for elections that I believe will help add to the smoothness of the process.  The process is now less hurried and more "luxurious" -- we take our time.  Although this draws out the process on the negative side, the positive outcome is that the elections managers and everyone else behind the scenes now has sufficient time to take care of their responsibilities and respond to unforeseen circumstances.  The schedule has time built in to account for problems coming up.  This model schedule will work for any election, because all elections involve the same primary events.  Here is a rough copy from the schedule part of the document:

Week 1: Announcement of Election

• Monday: USG President announces upcoming election
• Thursday: First open house
• Friday: Second open house
• Sunday: Candidate registration deadline

Week 2: Campaigning

• Monday: Campaigning begins
• Friday: Ballot check
• Sunday: To-date expenditure reports due

Week 3: Voting

• Monday: Voting begins
• Wednesday: Voting ends
• Friday: Results announced

Week 4: Run off voting

• Monday: Run off voting begins
• Wednesday: Run off voting ends
• Friday: Results announced

The document then breaks down each day and provides extremely detailed information about what happens on those days.  The detail goes down as far as to describe what information and attachments the USG President should include in his email, what type of information will appear on the public spreadsheet for the candidates, and the course of action if complaints are received.

Remaining Sections

The "Helios" section will outline information about Helios and include technical guides for non-technical users.  This is the part that will give advice about how to handle the trustee keys to make sure one doesn't get lost.

The "Voting Mechanisms and Methodology" section will describe the two mechanisms we currently use: run off voting and approval voting.  It will describe why we use these mechanisms and how we use them.

The "Avoiding Common Errors" section will be a place where I list the failures of previous elections and give an in-depth analysis of what went wrong and why.  It's about learning from our mistakes -- not making the same ones over again.

The "Troubleshooting" section will essentially be a "worst case scenario" guide that lists some tricky problems that we anticipate could happen and some suggestions for how to solve them.  It certainly will not give cookbook-like directions -- it would be wrong to assume that all situations can be dealt with so mechanically.  However, at the very least, this section will give some much-appreciated guidance to the elections administrators who are dealing with some potentially muddy problems.

Closing

We've come an extremely long way since the beginning of this project back in March when I approached Connor and expressed an interest in cleaning up elections.  Unfortunately, the entire image of the USG has been tarnished by a string of poorly run elections, and we have inherited this bad image.  These elections fiascos have been distracting the students from what the USG actually is supposed to be doing, and it has been diverting the USG's resources away from campus improvements and towards cleaning up these problems.  The time I spent on this project could have served the student body better immediately if put to other projects.  However, someone had to bite the bullet and clean up this mess already so future administrations don't have to keep dealing with all of the problems that we have had to deal with this year.  Elections shouldn't be such a big deal.  The purpose of elections is to elect USG members who will improve the campus based on student concerns, not to create front page fiascos for the Daily Princetonian.

Hopefully the work we've done so far has put us on a path towards that "ideal" election.  We have an entirely new technology for casting ballots and tallying results, a Candidate Handbook  to bring candidates in the know, and an Administrator Handbook in progress that will eventually be a definitive resource for future elections managers.  For this election, we also have a team of extremely dependable, competent, and devoted elections managers.  That's a great start!

But we're not done yet.  In fact, we'll never be done, I think.  Elections are very tricky, and the "problems" that arise are just part of what elections entail; we need to accept this and move on.  We need to keep working on this, though hopefully to a far lesser degree than what I've had to do this year.  When you have highly political people clamoring for power, you're going to have problems.  That is to be expected.  But if the elections managers keep on top of the process, rely on the resources we are developing for them, and improve these resources based on what they learned from their election, our elections will continue to improve.  We may never reach perfection, but as long as we are driving in that direction our elections are on the right track.

Two weeks ago I delivered my third presentation to the senate regarding the elections project.  This was the first presentation to the senate since we started working with Helios.  The purpose of the presentation was to explain what Helios is, how it works, and what we can do to use it.

The Presentation

I began by going through a quick review of how we got to where we are now:

It certainly wasn't a simple process!  There were plenty of dead ends and u-turns along the way.  But that is what made it such an exciting project!  If you're new to the blog, you can read through the chronicle of blog posts below to get the full picture if you're interested.

Download the presentation here!

Then I discussed two of the critical features of Helios:

1. Ballot Casting Assurance
   Each ballot you cast generates a unique tracking number.  At any time after you cast the ballot, you can go to the Ballot Tracking Center in Helios and make sure that this tracking number matches the one you received when you cast your vote.  If they match, you can be confident that your vote was successfully cast and has not been modified.
2. Universal Verifiability
   Any observer, including a third party auditor, can verify that all of the votes were correctly tallied.  During the UCL election using Helios (see August 4th post below), they hired a third party auditor to do exactly this.  The auditor reached the same conclusion as Helios, and thereby verified the election.

Helios is based on cutting-edge technology -- straight from the lab, you could say.  And I half-jokingly proclaimed that our use of Helios would mean that we have the most advanced election system of all student government elections around the country, world, and cosmos.  But all joking aside, Helios is a huge leap forward in online voting technology, and it is an ideal solution for student government elections.  Not only is it secure, but it is also absolutely free!

That's right!  Helios will not cost us anything.  The software is free, and by using Google Appspot to host the service, the hosting is also free.  As a GNU programmer would point out, the adage "You get what you pay for" definitely doesn't apply here.  Helios could potentially be more secure than non-free alternatives.

Next Steps

At this point, we are 100% invested in using Helios for the class of 2013 election this fall.  For me, this is a huge weight off my shoulders.  There was a point in mid-August where nothing seemed to be working and I wasn't sure if we would have anything in time for this election.  But luck seems to have been on our side.

Timeline

Last week I met with Addie Darling '12, the senior elections manager, to plan the timeline of this election.  In the past, the protocol followed by the elections administrators has been as much to blame for the elections problems as the system itself.  To change this, Addie and I thoroughly planned the whole process out, down to details including the time at which emails will be sent and what will be included in these emails.  This timeline is available now in the elections center.

Playing It Safe

Although I'm thrilled that we are launching Helios, I am also concerned about the adoption of Helios.  I don't have any concerns about Helios itself -- it works.  Period.  The biggest concern I have is that voters will understand how to use Helios.  Admittedly, the increased security in Helios comes at the expense of simplicity, though certainly not to the point of hindering usability.  For example, there are a few extra steps to using Helios not found in the old system.

Here's an example of something I'm concerned about: the login procedure.  In Helios, you don't log in until immediately before you submit the ballot.  Even if you aren't eligible to vote in the election, you can go through the ballot, make choices, encrypt the ballot, and get a tracking number.  However, at this point you must log in to cast your ballot.  This is very different from our old system, where you logged in first, made your choices, and clicked submit.

But it's not that eccentric!  Think of it in terms of a paper ballot.  Anyone can get the paper ballot and mark choices, but when you go up to the ballot box to deposit your ballot, someone checks your ID to make sure you are eligible.  This makes sense, right?

Test, Test, Test

In order to flush out confusion that voters may have, we have been having groups of people test Helios.  We will continue with a larger-scale test next week.  This test will be confined to the class of 2012 to test Helios' ability to check voter eligibility by class year and since it will allow me to reach out to my friends to help.  Addie and I will be sending invitations to test Helios to our friends and then getting feedback.  If you would explicitly like to participate in the review of Helios, I'd be happy to include you.  Just send me an email to yaro@.  We hope to glean from these user experiences the pieces of Helios that cause the most confusion.  Then, based on this feedback, I can tailor my instructions to explain certain parts in more detail.  Also, we can use this feedback to make changes to Helios for a future election.  (It would be unwise to make modifications to Helios now, right before the election, because doing so could introduce problems into the program).

Documentation Galore

Ben and I agree that documentation, a "how-to" guide to Helios, is crucial.  Therefore, I'm going to go overboard on this end.  Video demonstrations, FAQs, pretty pictures, and unicorns.  This will be linked to by a "Help" link at the bottom of Helios.

Feedback Requested

The best way to improve Helios is to learn from real use.  To that end, I'm going to set up a survey to get everyone's feedback on Helios after they use it.  This will help me focus the guide and further refine Helios

Now, I'm off to set up the test election.  The contest between Mickey Mouse and Chuck Norris for the class presidency is heating up!

Message to Registrar and Elections Committee

Below is the message I just send to the Registrar and all of the other contributors to the project:

Hello, Ms. Griffin, Dean Dunne, and members of the committee that assisted with the election project this summer;

It's been a while since our last meeting regarding the USG elections, and I'm thrilled to announce that, in this time, the USG has settled on our solution: Helios.

Dr. Ben Adida and I have been working tirelessly along with members of OIT's Security and Data Protection group, the USG, and other voting security experts from within and beyond Princeton.  Through all of this, we have a tangible result: Princeton's very own instance of the Helios voting booth, an instance that is completely ready for us to use in the upcoming election.  It integrates with Princeton's Central Authentication System and successfully checks voter eligibility based on class year.  Our plan to launch Helios for this fall election with the class of 2013 is well underway and right on track for a successful launch in two weeks

Helios is a thoroughly-tested system -- our election is far from the first to use Helios.  In fact, as I may have mentioned at our August 4th meeting, the Université catholique de Louvain in Belgium used an earlier version of Helios to elect their university president.  This high-stakes election had as much publicity involved as you might expect if we were analogously to elect President Tilghman's replacement.  In this election, the university ended up praising Dr. Adida and Helios for enabling them to conduct such a well-run and reliable election.  Since then, Dr. Adida has made a number of presentations on Helios at universities and voting security conferences, and his peers in academia have also contributed to giving him feedback that has allowed him to tighten the security even further and create the version of Helios, version 3.0, that we have today.

However, even though I am confident that there are no problems inherent to Helios, there are potential challenges to launching any new voting system to such a large population of voters, especially one as advanced as Helios.  As such, we are planning a full-scale test election next week, in which the class of 2012 will be the first class to use Helios by responding to a simple survey through Helios.  Through this test, I hope to identify which parts of Helios voters find most confusing so that I may create guides and documentation to address these causes of confusion.  Then, for the December election, we can perhaps modify Helios to address these concerns.

In addition, we will use this test election to conduct a full-scale test of the component we have implemented that verifies voter eligibility.  You may be comforted to know that this system was built using the very same authentication procedures implemented by James' WebSurvey.  As a result, Helios will be equally as sensitive to voter eligibility as WebSurvey was; Helios' ability to discriminate between eligible and ineligible voters is equally as powerful as the system used by WebSurvey.  In fact, it is the very same system.

One notable difference between Helios and WebSurvey that is of explicit interest to this committee is the role of the elections administrators, such as the USG Elections Manager and the Office of the Registrar.  In WebSurvey, a representative from the Office of the Registrar logged in to click a button and tally the votes.  This process constituted "Registrar Certification" in previous elections.   The process with Helios is similar, albeit slightly more secure. 

In Helios, there can be a number of trustees that divide the power to decrypt the ballots and tally the votes.  For our elections, the USG is proposing to distribute this power between two trustees: the Office of the Registrar and the USG Elections Manger.  Through this arrangement, the results of the election cannot be tallied or published until both trustees input their unique decryption keys.  Without both of the decryption keys (think of these as passwords, analogous to physical keys), no single person can gain advanced access to the ballots or the results.  This is similar to how a personal vault at a bank might work -- both keys must be present to "open the box."  No single party acting on his or her own could gain advanced knowledge of the vote counts -- this includes any member of the USG senate or the elections manger herself.  It is also, critical, though that neither of these keys (which are strings of characters like passwords) be lost, since if one of the keys is lost it will be impossible to tally the votes.

As a result, elections using Helios will still depend on a strong relationship of cooperation between the USG and the Office of the Registrar.  I would like to meet with whoever in the Office of the Registrar will be responsible for this "trustee" roll sometime soon so that we may learn the full protocol from Ben.  We can then use the class of 2012 test election as a way to have a "dress rehearsal" of our roles as trustees.  The test election will take place next week, concurrent with the campaigning period for the actual election.  Then, in the week following, the actual election with the class of 2013 will take place using Helios.

To everyone on this committee, thank you for all of your generous assistance along the way.  I cannot adequately express how thankful the USG is for the level of cooperation between so many parties in this project.  This has been a complicated project, involving many people, and with numerous abrupt changes in direction along the way.  Our successful launch of Helios will be a standing testament to this remarkable cooperation and the achievement we have conjointly made.  I anxiously await the full launch of Helios in two weeks!

Sincerely,
Michael

There hasn't been an update on this blog in a while, but that's because I've been hard at work on a not-so-secret weapon.  You see, I have to confess that I was slightly disingenuous in the last blog post.  I insincerely wrote:

"So we still can use WebSurvey to run the election in the fall... this seems to be an acceptable option, and frankly the best that we can do."

In fact, we can -- and most certainly will -- do better.  All along, I was never actually content with settling for WebSurvey again; you can't succeed by settling for second-best.  Unfortunately, at the time of that last meeting and the blog post, "first-best" wasn't a viable option... yet.  But a few weeks, and a few hundred emails later, I present to you Princeton's very own functional instance of the Helios Voting Booth.

The Bait and Switch

Even though Helios was a mature system, ready to be used, it was not certain how Helios would interact with the University's authentication infrastructure. This additional connection that needed to happen was what stood in my way of convincingly proposing that we use Helios for the fall election.  Without solid evidence that Helios works for us, I would be standing on an unreliable footing -- pitching vaporware.  At the time, the best choice we could make was to fall back on WebSurvey, our old system.  I was okay with this decision since I knew that I'd be able to prove Helios in time for the fall election and that we wouldn't actually have to use WebSurvey.  Making this "decision" would then buy us time to do exactly that -- prove Helios.

The Missing Links

Every student has a personal netID that is the student's gateway to online services, from the Office of the Registrar's SCORE to University Webmail.  For elections, students log in to cast their votes using their netIDs.  Therefore, for us to use Helios, we had to configure Helios to play nicely with this infrastructure so that students could just log in with their netIDs to cast their ballots, and to ensure that voters cast only one ballot. (Actually, with Helios, voters can cast as many ballots as they like, but only the last one they submit counts.  But more on that later....)

We also needed to make sure that only eligible voters cast ballots.  In the upcoming fall election, only members of the class of 2013 are eligible to vote, so we have to make sure that only members of the class of 2013 can actually cast a ballot.  Lacking magical powers to deter ineligible voters (don't let Whitman College fool you into thinking this is Hogwarts), we had to somehow determine the class year of a voter.  The way we accomplish this is by using voters' netIDs to determine who they are via the university directory, the LDAP.  Give the LDAP a netID to look up, and the LDAP returns the class year of the student associated with that netID.  By simply checking whether that class year is eligible for the given election, we have successfully verified voter eligibility.

Although the LDAP is accurate 99% of the time, it is not a perfect database.  The information in the LDAP may be outdated because of extenuating circumstances, or a student may have requested that her information not appear in the public LDAP directory.  In these cases, the LDAP may erroneously indicate that an eligible voter is actually inelligible.  A better system would interact with the Registrar's database, which is more reliable.  However, such an interface would take too much time to implement right now, so we will tackle that hurdle later and instead handle LDAP issues on a case-by-case basis as they arise.

I will admit that this is settling for second-best, but I will also defend this choice with the following:

1. The old election system used this exact same method to determine eligibility, and suffered from the same problems, so there is a zero net gain/loss, and
2. This is a complication I identified early in the election redesign process, before Helios was even part of our vocabulary, and one I am committed to overcoming when time permits, and
3. We simply don't have enough time between now and the fall elections to make it happen.

The Goods

So after all of our work, we now have an implementation of Helios that successfully authenticates voters using CAS, the netID interface, and successfully verifies voter eligibility using the LDAP public directory.  At this point, Helios does everything to authenticate voters and check their eligibility that WebSurvey does.  But Helios is also... Helios.  And what exactly is Helios, you may wonder?  And why should you care that we're using Helios rather than WebSurvey?  Stay tuned for a future blog post where I'll actually outline all of the benefits of using Helios.  But for now, here is a video demonstration of Helios as it is right now.  I'd go into more detail, but I've got to get back to work on our remaining tweaks to Helios and then get the final approval to use Helios for the upcoming election.  Wish us luck!

Oh, and by the way.  Remember the $7,500 to $15,000 budget of last spring?  Well, Helios is free.  Now doesn't that just put a cherry on top?