Princeton Undergraduate Student Government

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:

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 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 We simply don't have enough time between now and the fall elections to make it happen. In conclusion, Helios with the LDAP limitation is still better than WebSurvey with the LDAP limitation, and we'll  resolve the issue as soon as we can.

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?

 

Today we had our most productive meeting so far.  We now have a fairly concrete plan to succeed.  We reviewed our single proposal, reviewed the other options I proposed, and settled on a compromise solution.  But first, the background:

Introducing Dr. Ben Adida

I have introduced Dr. Kernighan and Dr. Felten before in this blog, but Dr. Adida is a new and most welcome addition to the team of experts I've been in touch with about the project.  I requested an email be sent to all Princeton Computer Science undergrads and grads, and one of the handful of responses I received was a suggestion to look into the Helios Voting System developed by Dr. Ben Adida.  Although I had come across a slew of run-of-the-mill online voting systems in our previous research, as I explored Helios, I recognized that this voting system was different from the rest.  It's the difference between an abacus and a TI-89; other voting sites count things, but Helios brings some sophisticated computing power.

Dr. Adida (who asks to be just called Ben) is a graduate of MIT who is a postdoctoral fellow at Harvard's Center for Research on Computation and Society.  He researches security and privacy in voting, health records, and web applications.  He is a member of the program committee for the Workshop On Trustworthy Elections (WOTE) and the USENIX/ACCURATE Electronic Voting Technology Workshop (EVT).  In fact, he and Dr. Felten will be brushing shoulders on August 10th at the EVT/WOTE 2009 in Montreal.  Could you imagine a better team of experts to advise our project?

Dr. Adida was kind enough to offer to speak with me by telephone last night.  I had only begun emailing him the day before.  We discussed his Helios system, Princeton's predicament, and the MedForward proposal.  Below are a few highlights from the conversation:

All elections have hiccups.  What differentiates successful elections from failures is how these hiccups are handled. Our best bet with our elections project is to be "iterative and conservative."  Rather than completing the system in one shot, it is in our best interest to make realistic goals and continuously develop the system for some time until it is ready. Although Princeton currently uses Single Transferrable Vote for certain election needs, Range Voting could be a more straightforward alternative. With the Helios Voting System, voters get the freedom to observe the election and make sure everything is okay.

The Helios Voting System

So I've mentioned the Helios Voting System, but not yet what it is.  So what is it?  In short, it is a cutting edge online election system that puts the power to audit the election in the hands of the voters and observers.  Helios allows voters to make sure their vote counted, to modify their vote before the close of the election, and to audit the entire election once the scores are tallied.  It leverages advanced cryptography to ensure vote security and voter anonymity, while simultaneously improving overall election transparency.

Learn about cryptography and voting in a Google TechTalk video presentation given by Dr. Adida.

This all sounds great, but does it actually work?  To my delight, Helios actually works very well.  In fact, the Université catholique de Louvain (UCL) used Helios to conduct an election for their university president, and it was no small deal. Below is an excerpt from their site (warning: it is a Google automatic translation cleaned up for enhanced English readability by me)

It is apparent that, with our 24,000 voters, electronic voting is the best solution, and that this system must be reliable and ensure the highest degree of security and confidentiality. Fortunately, the election commission has the help of Professor Jean-Jacques Quisquater, an expert in cryptography.  After studying a variety of voting systems with his team, he suggested Helios, a system designed by a Harvard professor (Ben Adidas).Three reasons motivated this choice, says Professor Olivier Pereira. First, voters have a high level of control at each stage, and we can verify that everything is operating correctly, and thanks to the internet, a voter can verify that her vote has been recorded. This system produces the weighted count of the ballots submitted by voters, nobody (nor even a computer) can ever determine who voted for whom.  Finally, the system makes it virtually impossible to vote incorrectly: first, the voter is prompted to confirm his vote, and then he has the opportunity to vote again if he thinks he is having a problem or made a mistake (that is one of the great peculiarities of the system). Helios has, of course, been adapted to the needs of the UCL. This has been the work for several months of Olivier Pereira and Olivier de Marneffe  in collaboration with Ben Adidas and the General Information System (ISMS) [presumably the equivalent of Princeton's OIT]. Among the challenges, they had to ensure "the soundness of the system given the large amount of data to be processed and the risk of attacks." That is why he suggested service providers, namely Amazon and Google: Amazon hosts the interface designed by UCL, and Google will store the data. "The best way to ensure the availability of the voting system for the duration of the election was to have extremely powerful servers  arranged across the world.  That is what we use Google and Amazon," explain two members of the technical team.

Source: UCL Website via Google Translation

During the first round of voting, one of the candidates missed the majority by just 2 weighted votes (faculty votes counted more than student votes in this election).  An independent company also audited the election, and certified that Helios had correctly tallied the votes.  A second election was held, and that candidate finally achieved the majority he needed.  In a paper detailing the outcome of the election, Dr. Adida and his colleagues at UCL write:

The deployment of an open-audit voting systems brings a number of small changes in the voting process, which inevitably makes voters suspicious. Numerous presentations were given and discussions fostered make voters more familiar and comfortable with the system. The features that were the topic of significant questions and debates were: (i) the possibility to revote, (ii) the identification of the voter at the time of ballot submission (instead of before the ballot creation), and (iii) the point of the bulletin board audit day (which delayed the announcement of the election results). From anecdotal evidence and the small number of complaints, it appears eventual acceptance of the system was quite high.

What Can Be Done with Helios?Helios will soon be released as an open source project written in Django, a rapid web development framework based on Python (An older version of Helios is open source too, and is available here).  The Django connection is particularly exciting, given the number of students at Princeton who have worked with Django and know how to use it.  In fact, the group of students that came together under the assumption that they would be building a voting system from scratch had planned to use Django anyway.  So this means that rather than starting from scratch, this group could simply extend the work of Dr. Adida, and modify Helios to meet our own specific needs.  All of the hard work of ensuring the system tallies votes correctly has been done!  All that remains to be added is the administrative and registration component, where candidates and referendum advocates can sign on and register for the election, and where the elections managers can manage these positions.  Amazing, right?

The MedForward ProposalWhen we sat down for today's meeting, we began by reviewing our one and only response to our RFP.  I highlighted some of the benefits and drawbacks of this proposal:

 

Positive Negative On TimeMedForward promises to deliver the system on time. Lack of Elections ExpertiseMedForward specializes in building websites for medical professionals, not building secure election systems. Meets Most RequestsThey have committed to satisfying most of our requests for the implementation. Use of ASP.NET and Windows Server 2003The platform has a steep learning curve if students ever need to modify it, and it will be difficult to obtain affordable server space running Windows Server 2003 and to keep running this older technology for up to 10 years. Potential for Future SupportMedForward will likely be able to support the system after it is built, through the lifetime of the system. MedForward Retains Intellectual PropertyAfter Princeton pays to have the system built, MedForward will retain ownership of the code and related intellectual property. On BudgetThe proposed price is within our original expectation of $7,500 to $15,000. Potential to Become ExpensiveThe price does not include the Single Transferrable Vote system, which will cost $2,000 more to develop, and combined with the additional costs of support and maintaining the required server, the lifetime costs could approach $20,000.

After weighing these positives and negatives, we decided against choosing the MedForward proposal.  Chief among our concerns was how developing voting systems is not something MedForward has done before.  After consulting with Dr. Kernighan and Dr. Adida, both expressed concerns about the complications inherent in developing online voting systems, and were unsure how well MedForward, or anyone, could implement the system we designed with just over one month to do so.  Dr. Adida recalls one voting system he built taking two years to complete.  And Dr. Kernighan wrote to me via email, "MedForward is presumably a fine company, but they claim no experience with voting systems, which have different constraints than most commercial systems.  For instance, voting systems have to authenticate the user, permit him or her to vote only once, and make it impossible to determine how the user voted." It's far more important to me that we come upon an airtight system that will last for up to 10 years, rather than settle quickly and potentially regret making a hasty decision.  So although I was extremely pleased to receive the proposal by MedForward, and we appreciate their offer to help us, in the end we felt that it was too risky to select them.  This decision was unanimous among the committee members in attendance.UPDATE 9/29/09: At the request of MedForward, I have redacted the price of the project in their proposal.

Download the MedForward Proposal

What Now?

Considering that we decided to decline the proposal from MedForward, we now found ourselves without a developer, and no guarantee of a new system by September.  This looks bad, huh?  Actually, I think we're in even better shape than we would have been if we had begun developing the system with a professional developer.  Let me explain.

After speaking with Dr. Adida, I know that our September deadline to develop a complex voting system may have been too optimistic.  I was cautiously optimistic last May, but it looks like my cautious choice of words, "it would be 'ideal' to have the new system in place for the Class of 2013 elections next fall," was duly necessary.  This isn't as much an "I told you so" as it is a recognition that this project was more complicated than we had hoped.  So even though we won't have a new system in use by September, we have accumulated crucial insights from the panel of experts and have discovered Helios.  In the end, the result will be better than if we made hasty decisions in order to have the system ready by September.

One Suggestion

I suggested to the group that we may be able to use a minimally adapted version of Helios in order to run the class of 2013 elections this fall so that we can at the very least have something new and reliable in use to tally the votes.  Helios doesn't currently support Single Transferrable Vote, but the upcoming election doesn't require that.  In fact, Helios can do everything WebSurvey (our previous election system) does for the fall election, plus Helios offers the advanced security and transparency features. All that would have to be changed would be to allow Helios to use our CAS netID authentication system, and to communicate with the Registrar's database in order to verify the class year of the voter.

So, considering that I hope to use Helios as the backbone of our new system we will develop, I suggested we begin using Helios for the fall election instead of WebSurvey.  This would be an ideal election to begin using Helios: it is the smallest and simplest of all of the elections.  However, the committee was uncomfortable using Helios right now.  Instead, they suggested that we continue using WebSurvey, so this was the option we are compelled to take.

More WebSurvey?

You may be saying to yourself, "More WebSurvey?  That's the system we had so much trouble with in the first place!  How can you claim that we've made any progress if we're still using WebSurvey?"  That's a good question, and the answer requires understanding exactly why we've had trouble with WebSurvey to realize that WebSurvey didn't cause the problems we've had, it only contributed.  As Daisy says in The Great Gatsby, "it takes two bad drivers to cause an accident" (not a direct quote).  So who was the other "bad driver?"  Sub-par elections administration.

Pointing fingers is a poor way to make progress, but we need to point the finger so we know where to make improvements.  So I'll review some of the reasons why previous elections have been problematic:

Winter 2008

Problem 1: Admin Access

In the news

"USG Elections Process Under Question" - November 19, 2008 (DP) "Voting delays explained at USG meeting" - December 8, 2008 (DP) "Weinberg '11 wins; USG nixes revote" - December 10, 2008 (DP) "An election to Remember" - December 12, 2008 (DP)

What happened?

Because of unusual circumstances in which the USG President openly supported a candidate and spread misinformation about another candidate's endorsement, the senate was tasked with deciding whether to conduct a revote after the original vote had already taken place.  There was suspicion that the USG President based his sway on whether to conduct a revote on knowledge of the turnout of the first vote that he wrongfully obtained via logging into the voting system to obtain the results.

What can be done to prevent it?

It was suspected that the USG President accessed the election results by logging in with the USG@ shared netID, which, in addition to the USGVote@ netID, had access to the voting system and the results.  Immediately following this allegation, changes were made to block the usg@ netID from gaining access to the system.  Therefore, this type of problem has been addressed.  However, the USGVote netID could also potentially be shared, which would grant access to anyone with the password.  Instead of using these shared netIDs to grant access, I suggest using personal netIDs, which are less likely to be shared and provide additional security.

Problem 2: Incorrect Vote Count Published

In the news

"Elections Audit Uncovers Erroneous Results" - May 22, 2009 (internal) "USG elections audit uncovers error; Class of 2012 Senate seat vacated" - May 24, 2009 (DP)

What happened?

The source of the problem was a quotation mark in one of the candidate's names.  This quotation mark caused the system to ignore votes for two candidates.  Every time a vote was disregarded, an error message was printed to the log where the vote counts are displayed.  There were 392 of these error messages.  There were other, negligible error messages, for when someone chose the same candidate twice for a senate seat.  The elections manager and the Registrar did not notice the unusual error messages, nor notice that the sum of all votes counted was remarkably less than would be expected.  The result based on the erroneous vote counts was published, but vote counts were not.

What can be done to prevent this?

First, the elections manager can more carefully inspected the system output to check all error messages and ensure that they don't affect the outcome of the election.  Next, the elections manager can compare the total number of votes cast with a calculated expected voter turnout, where this expected value is based on previous elections.  Then, the Registrar can double check the elections manager's checking.  And finally, the vote counts can be published, so that the public can also double check that votes were reported for every candidate, and that the vote numbers generally seemed to follow public preferences.

Spring 2009

Problem 1: Election start delay and erased votes

What happened?

Students began voting before the USG president had announced that voting had begun, and the ballot they were voting on was premature.  The USG president announced the actual start of voting when the ballot was ready, and all votes cast before then were not counted.

What can be done to prevent this?

Voting should not begin until the USG president's official announcement when it has been confirmed that the ballot is ready.

Problem 2: Incorrect scoring on Referendum I

In the news

"Correction to Referendum 1" - May 9, 2009 (internal) "Corrected referendum results show greater discontent" - May 15, 2009 (DP)

What happened?

There was a mismatch with how the elections manager created the XML file that creates the election, and how the election system tallied the results.  As a result, some responses were inverted.

What can be done to prevent this?

The XML file that creates the election (for WebSurvey only) can be verified before it is used.  And for a future system, there would be no need to manually map the database values with the choices -- it should be completely automatic so as to avoid any possibility of confusing them.

Notice a Trend?

Given these examples of problems that happened, the trend you may notice is that there were no problems that couldn't have been avoided were there some more comprehensive election oversight by humans.  Without a doubt, the technical system seeded some of the problems, but none of the final problems that occurred weren't preventable.  A better election protocol, including more time built in to allow for careful verification of all parts of the election, could compensate for these issues.

So what this means is perhaps the best change we can make is not to the technology but to ourselves.  The "ideal" voting system I designed, and we will still design, will help alleviate some of the issues that would require human oversight.  But that only makes it easier.  As Dr. Adida commented, all elections have problems.  The difference between a successful election and a failed election is how the administrators handle them.

Advice from the Expert: Dr. Ed Felten

As I mentioned in a previous post, Dr. Felten has become a part of our team of expert consultants.  When I mentioned the class of 2012 senator debacle, Dr. Felten offered:

Having read about the past botched election, my first thought was that the error would have been evident if the system reported results more fully and to a broader audience.    Just seeing no votes for certain candidates would have been a strong clue that something is wrong -- and the fact that the number of votes reported was many fewer than the number of voters would have been another giant red flag.

Therefore, I think it's in the best interest of everyone for the USG to commit to reporting all vote counts to the public.  This means every election, every position, and every candidate.  But Dr. Felten also agrees that the technology needs to change, too.

The people who saw the debugging output could have caught the error, in principle, but putting the blame on them seems too easy, and in my view that would miss some serious problems in the technology and -- at least as important -- in the human processes used in the election. The problem would have been detected if

(a) the system had shown voters the choices tabulated for them, at the time they voted, or

(b) vote totals for each candidate had been reported to the public or even to the candidates, or

(c) the error messages had been intelligible (it was a big problem that the real error messages looked very similar to messages that would normally occur), or

(d) the system had displayed a count of the number of errors of various types, in easy-to-read format, or

(e) the error messages had occurred somewhere other than a giant file of random-looking debugging output, or

(f) the system had been programmed to raise a red flag when the number of votes recorded was far less than the number of voters, or ....

Safeguards against error are the most important part of an election system.   Often the best safeguards are not technological at all, or involve only easy technical changes such as providing clear error reporting and building simple consistency checks into the system.

If you're wondering what the election output looks like, download the election output from the original class of 2012, December '08 election below.  This is an excerpt from the entire output, which includes the rest of the positions and referenda.  The header was added by my text-editing program when I made the PDF file, but the actual text as shown is unedited.  This is what the elections manager reads in order to determine the winner, and this is the text the Registrar reads to certify the election.  A little confusing, right?  No wonder there have been so many problems!

Download the original election output from the class of 2012, December 2008 ballot

 

Making WebSurvey Work for the Fall

So we still can use WebSurvey to run the election in the fall, as long as we implement a new, more thorough election protocol in order to prevent and mitigate any hiccups that can (and likely will) occur.  Given this additional time, we can then develop the system to make the technology work more effectively, too.  Although I would have liked to have had something more tangible to show for our work by September, this seems to be an acceptable option, and frankly the best that we can do.

What's Next?

Although we won't be using Helios for the fall election, and we won't have a new system developed by then, we will be simultaneously developing our own system that works with Helios and continuing to accept proposals from commercial developers.

By November 1, we will stop taking proposals and then compare the proposals we receive from commercial developers with the system developed by Princeton students that interacts with Helios.  We may then choose the system developed by the students, or we may select a commercial developer to execute the system.

What's the Timeline?

Starting immediately, the IT Committee and the Election System Developers will begin developing an administrative component that will interact with Helios (I'll continue describing this below).  By the first USG senate meeting, I will have a proposed protocol for the election.  Immediately after this protocol is adopted, we will begin planning for the election, which will include a meeting with the OIT technician responsible for WebSurvey, the elections managers, certain USG representatives, and the Registrar.  The election will take place in the beginning of October, using WebSurvey.  Then, in late October, using whatever parts of the Helios-USG collaborative project that is ready, we will conduct a pilot election -- perhaps a non-binding survey, a Mr./Mrs. Princeton contest, or just a mock election.  Based on that election, we will have gained valuable insight to how we can modify the system to be even more airtight.  Then, by November 1 (or around then), we will stop taking proposals and convene to review these proposals.  Then, we will compare the Helios-USG system with the top proposals (assuming there are any), and choose the best system.  If we decide to choose a commercial developer, then we will begin developing with them.  If we choose to use the Helios-USG system, then we will continue modifying that to be ready for the winter elections.  And then we will continue tweaking the system between elections until it is officially completed.

What will the new system look like?

If you haven't already visited www.HeliosVoting.org, check it out now!  In fact, create your own sample election, and vote in it.  You'll have to login with some Google ID, like a GMail account, since the system runs on Google's servers.

Helios already conducts the actual voting part very well, but it lacks the candidate/advocate self-registration aspect we would like to include.  The thought I have is that the student developers will create a standalone system (I'm informally calling this part "Luna."  And yes, I know Luna is Roman, not Greek like Helios, but I think "Luna" is more mainstream than "Selene," the Greek counterpart.) that allows candidates/advocates to register for the election and the elections manager to manage these candidates.  Then, once all candidates have registered and are verified, the elections manager essentially "flips a switch" that sends all of the information over to Helios for Helios to then create the ballots and prepare for voting.  This will create a special barrier between the two systems that will keep Helios as protected as possible.

However, before we actually decide what we are going to do, I have to arrange a phone call with Dr. Adida so we can carefully plan this.

As the wise Kel Mitchell once said, and the ever-sagacious Coolio sang, "Ah, here it goes!"

There have been a few important developments recently.

1) A bid comes in

Our first bid has come in on the elections project.  I will refrain from discussing the individual bids until all of the bids we could potentially receive have been submitted so as not to give other bidders any information they shouldn't have right now.  But I'll definitely post more about all of the bids once we've stopped taking them in.

2) Dr. Felten offers his support

Dr. Felten responded to my initial email, offering to provide whatever level of support his schedule permits.  I am excited to have Dr. Felten's expert advice contributing to our project

3) Message sent to COS grads and undergrads

A message was recently sent to all COS grads and undergrads requesting all those interested in either coding or advising to contact me by Thursday.  I hope to get some positive responses.

At today's meeting, members from the Princeton Survey Research Center joined us, further expanding what I will now call the USG Elections Advisory Council.  This interoffice council that will continue to meet through the summer now consists of the following members:

Organization Representatives Undergraduate Student Government Michael Yaroshefsky, IT Chair Office of the Dean of Undergraduate Students Thomas Dunne, Associate Dean Office of the Registrar Polly Griffen, Registrar Amy Hughes Laurie Smethurst Anahit Mailyan OIT Departmental Application Services (DAS) David Herrington, Director James Chu OIT Technology Consulting Services Salvador Rosario, Manager Matthew Immordino Princeton Survey Research Center Edward Freeland, Associate Director Naila Rahman

 

Since the previous meeting, Matt Immordino and I met to determine which features the ideal elections system would include.  For the meeting, I created the following three documents:

Elections Protocol(Simplified) System Feature Map System Implementation Outline

An outline of the elections process as it pertains to the electronic voting system

A high-level map of features and functions for the new election system

An intricate discussion of how I would propose approaching this project from a design perspective

Download Download Download

 

After my presentation, we discussed the possible alternatives for implementing the system.

One particularly noteworthy development since the previous meeting was that I was approached by Dan O'Shea, a recently-graduated Princetonian who in the not-too-distant past had served in a role in the USG similar to my own.  Dan offered to build the system for $5000 and to deliver it on our timeframe.  From the beginning, I had been averse to the idea of having a student (or former student) develop the system because of concerns about impartiality and support (I suspect Dan will not want to be providing technical assistance on this system ten years from now).

However, the prospect of coming in well under budget and working with a developer who has had previous experience managing USG elections made this possibility very attractive.  I proposed the following two solutions to avoid the "ongoing support" dilemma:

Have Dan work in conjunction with OIT DAS to develop the system, so that DAS can then support the system.  This would allow Dan to develop the software and DAS to simultaneously give feedback on the development and develop an understanding for future support needs. Whenever changes are required for the system, hire a student to make the changes.  In the past, students have been compensated for helping develop and maintain USG web applications, and it has been successful.

However, neither of these two options seemed to make this work.  First, DAS cannot operate in a way to make idea 1 possible -- that's not something they are willing to do.  Second, the general consensus was that, paid or not, finding students to reliably maintain the code is something we do not want to have as an ongoing burden.

Next, Edward Freeland of the Survey Center mentioned that the university had recently purchased a license to use the Qualtrics survey platform.  According to Edward and Naila, Qualtrics is a new system they use to conduct surveys with which they have been very pleased.  Qualtrics is in use by other universities, companies, and the federal government, so it is a proven system.  In addition, Qualtrics is eager to accomodate our custom needs, as demonstrated by their assistance with previous research surveys conducted on campus.

Naila had previously mentioned this project to Qualtrics, who had said that they could develop the part of the system that allows candidates to submit their own information to the election for $2000.  This modification would simply extend the existing Qualtrics architecture to meet our needs.  This is a reasonable price for this component, so I suspect that we could implement most, if not all of the desired features and still remain within our original maximum budget of $15,000.

However, there is one significant caveat: if the Princeton Research Survey Center decides to switch survey providers, as they recently did, and abandon Qualtrics, the investment we made to get Qualtrics to work for us would become almost useless without Qualtrics.  Even if the USG wanted to continue using the Qualtrics system, the annual costs associated with licensing the system would be prohibitive.

Therefore, it seems that the system has fallen back in the hands of DAS, from which we began.  But before DAS will build the system from scratch, we must determine conclusively that there is no other option available for purchase, an "out of the box" system.  Matt Immordino will conduct the bulk of this this research and give a report at our next meeting.  In addition, the administrators included in the council reach out to our institutional peers through Ivy Plus, a communications network between univeristy administrators, to consider what other universites are using.  By comparison, I will reach out to the students at other universites through the Ivy Council, a similar student consortium established between universities.

We plan to have our next meeting during the week of June 22nd.

In light of the frequent difficulties with previous elections, the USG has conducted an audit of all previous elections back through 2002. During this audit, an error was discovered in the class of 2012 senate election that took place this winter. The error caused votes cast for candidates Andreas Sakellaris and Michael Yaroshefsky to be disregarded when generating the final tally. OIT, who is responsible for the elections system currently used by the USG, confirmed that the algorithm that tallies votes had indeed malfunctioned. The original results processed by the system indicated that Julie Chang and Rebecca Lee were the top vote getters. After OIT corrected the malfunction, the system showed that Michael Yaroshefsky and Julie Chang had actually been the top two vote getters in that election.

Following this discovery, all involved parties were privately notified of the error. Michael Yaroshefsky could have accepted position as class of 2012 senator to which he was elected. However, he declined to accept this position, instead choosing to continue serving as IT Chair for the USG.  One of the two positions of class of 2012 senator is now vacant and will be filled according to the constitutionally-prescribed appointment process. 

Today, I had a meeting that included the registrar, Polly Griffen, and other associates in the Office of the Registrar.  Also joining us for the first time were members of OIT's Technology Consulting Services, Finance, Administration and Planning department.  The purpose of the meeting was to describe the expectations of the system in order to determine definitively how to proceed.  Namely, we will determine whether we can purchase an existing solution to meet our needs, or whether developing a custom system remains the best decision.

We began by developing a SIPOC value chain, determining the:

Suppliers Inputs Processes Outputs Customers (Receivers)

Going forward, I will be coordinating with Matthew Immordino of OIT to lay out a more specific list of requirements for the system.  Then, together we will contact vendors of elections software to see if they can meet our needs and at what price.  The original ballpark price OIT gave us was $7500 to $15000, so we are working to keep the cost under $15000.  Our next meeting is scheduled for June 8th.

Today I delivered a presentation to the USG Senate.  This was the second presentation regarding our effort to develop a new elections system to meet our needs.

During the presentation, I stressed the fact that USG elections are one of the two primary times during which almost everyone interacts with the USG (the other is lawn parties).  Every single election this year has been plagued by problems, many of which could have been prevented had there been some better elections management system in place.  This includes both the technical system and a detailed protocol.

This was the first time I announced my intention to develop alongside the  software an internal protocol.  From what I've seen while helping out during this past election, there needs to be a more clear understanding of who is responsible for certain parts of the election process.  It would be much more efficient if everyone could refer to a simple document that oulines everyone's responsibilities during the election cycle.

I then explained the expected price range of the system based on the estimate received from OIT during my previous meeting with them.  Since I expect the new system to last us 10 years (the current system was put together quickly and without any USG input, and it has lasted 7 years already), and there are 3 elections per year (freshman class, USG winter, USG spring), this works out to be 30 elections.  When you divide up the cost OIT gave us, that works out to be between $250 and $500 per election.  That's about inline with the cost of a study break.

You can download the presentation in PDF format here.

The following information was released on Thursday, May 7th to the Daily Princetonian by Cass Cliatt, the Princeton University Director of Media Relations:

1.  What went wrong with counting the votes for the USG referendum 1?The issue with vote counts was with Referendum 1, but it affected all four questions in that referendum. No candidate elections were affected, but we’ve seen the same error in previous voting on USG referendum questions and are working to address this. What occurred was that the program that counts votes expected the assigned selection by each voter to be in ascending order, but the reverse was the case. So, while the program expected that a value of 1 in a yes-no question would be yes, in actuality the value was supposed to mean no. The value 2 meant yes and 1 meant no.The other issue is that, in typical circumstances, zero is not provided as a value in such voting. So, typically, if a zero appears, the program reads it as the voter opting not to make a selection. A zero typically is read as a non-choice, and the program assumes the voter bypassed the question. This led to an incorrect reporting of the results, which was later discovered by OIT and reported to the USG’s elections manager. Unfortunately, the problem wasn’t discovered until after the original results had been provided to the USG and publicized.After the problem was discovered, OIT's technician responsible for the application went into the database and changed all existing 1 values to 2 for all four parts of Referendum 1, then all zero values to 1. These results will be now be recertified by the Office of the Registrar, which is the standard protocol for the results.2. How were the results affected?The results originally reported were in error. OIT found that some of the resulting values may not have been as intended by the voters, and administrators in OIT expressed deep regrets to the USG. The problem really demonstrates the need to have an updated and thoroughly tested election process in place for future elections, which has been the subject of continuing talks between OIT and the USG. And in fact, progress is being made on this front.3.  How will the problem be resolved?Again, OIT’s technician has gone into the system and adjusted the program to correctly count the votes, and now is working with the Office of the Registrar to recertify all the results. The correct results will be reported to the USG elections manager as early as Monday. In addition, OIT and USG are working together on designing new elections software in a project sponsored by the Office of the Dean of Undergraduate Students. The goal is to eliminate any possibility of a similar problem arising in the future and to ensure a secure system.

Today Dean Dunne and I met with Dave Herrington, the director of OIT's Departmental Application Services (DAS), and James Chu, the author of the current elections system and the soon-to-be author of the code for our next system.  DAS develops website applications for academic departments within the university.

During the meeting, we flushed out some special requirements for the system.  Dean Dunne and I reviewed the elections process and how the software comes into play.  We determined that it wouldn't be worth it to "fix" or update the current system.

Some critical features of the new system include:

Very friendly administrative interface with plenty of controls Direct link between candidate statements and the ballot Candidate management system built into the software Allowing individuals to submit referenda directly through the new system Enhanced security features to restrict access to the administrative panel Special features to detect malicious attacks

After our discussion, Dave mentioned that at the very least the project would require one month to complete.  Each month of labor will cost approximately $7500.  A more reasonable estimate would be two months, or $15000.  This was more than I had hoped, but given the complexity of the project, this seems to be a fair price.

From here, I will develop a comprehensive specification of goals.  We plan to then itemize these goals, and assign costs to each one.  Then we will determine, based on the costs, which particular goals should be attempted given the price and time constraints.

This week is your chance to run for a position on USG! Anyone interested in running for Class Government, U-Council, or USG Social Chair is required to attend a mandatory USG Elections Open House at either of the following two times:

8:30pm, April 13 (Monday) at the USG Office (Frist 204) 8:30pm, April 14 (Tuesday) at the USG Office (Frist 204)

Candidate forms will be due on April 17 (Friday).

If you have any questions regarding the elections process, please contact Sophie Jin (Senior Elections Manager) or Addie Darling (Elections Manager) with any questions or concerns you may have.

This elections cycle, the USG will implement its new and reformed elections packet, a proud product of the Constitution and Voting Reform Working Group, to guarantee secure and fair elections for all candidates. We strongly encourage you to run for a position on USG!

Today we had our first meeting with OIT regarding the elections system.  The purpose of the meeting was to trace the history of the current system and gain a little more information before the next election.  I learned that the current system we use was developed around 2002 when the Office of the Registrar decided to move away from using paper scantron ballots.  They asked OIT to develop a system.  OIT created the system, the Registrar approved it, and it went into service.  From my understanding, USG had minimal involvement in the process.  We then discussed a few minor technicalities of the upcoming spring USG election.

The Constitution and Voting Reform Working Group and the Information Technology Committee are working hard to devise new and improved means to ensure fair elections for the upcoming elections cycle. Through a collaborative effort involving the entire USG Senate, the working group promises tangible and reliable changes that will secure the USG voting process. Through significant adjustments in policy and the development of new technology, the USG believes that the elections process will run smoothly from now through future administrations.

Today I delivered my first (of what I assume will be a few) presentation to the USG senate regarding the new elections system idea.

During the presentation, I outlined a few of the problems I think the system has:

Custom coding the candidate statements (update: this appears to be incorrect.  There is an "automated" system in place, but it is very difficult to work with.  For one thing, the elections manager can't go in to edit candidate statements after candidates submit them.  Only the candidates can edit their own statements.) Miscommunication with the format sent to the Office of the Registrar for verification There seem always to be glitches in the system, such as people not being able to vote or candidates not showing up correctly The usg@ netID has access to view the election results, which could be a breach of security

I then outlined the mission of the project:

Mission: Our mission is to create a new election system that is secure, reliable, and manageable.  Secure: Allow access only to those who need it, only when they need it Reliable: Reduce the likelihood of interference in the elections prcess Manageable: Make managing elections as easy as posting to Facebook

You can download the presentation here.

The new USG administration has hit the ground running, tackling the most pressing issues that face Princeton undergraduates today. From civic engagement to the P/D/F policy, the USG has been working hard to develop sustainable policy solutions that will better the overall undergraduate experience. Specialized USG Working Groups comprising three to five USG officers address issues in their domain through conducting research, meeting with University administration officials, and proposing final policy solutions. Read more to learn about the wide variety of currently active working groups.