Trinity College Web Election Committee Report

January 30, 2002

Committee Mandate. 1

Committee Members. 1

Activities of the Committee. 1

Identified Problems with Paper Ballots. 2

ROSI Option. 2

Trinity Server Option. 5

E-mail Option. 6

Swipe Card Verification. 8

Corporate Options. 9

General Thoughts on Internet voting. 9

Research on Internet Voting. 10

Suggestions for Amendments to the Electoral Rules. 10

Recommendation. 10

Final Action. 10

 

Committee Mandate

The Web Election Committee’s mandate is to examine methods to automate the voting system at Trinity College and to report back to the Trinity Joint College Meeting on the feasibility of these options.

Committee Members

Jon Bell - Male Head of College (dfwjb@hotmail.com)

Emily Lord - Elected committee member - (emblee@hotmail.com)

Tanya Magnus - Female Head of College (tanya_magnus@trinity.utoronto.ca)

Michael Meeuwis - Deputy Returning Officer (meeuwism@trinity.utoronto.ca)

Andrew Morgan – Elected committee member, Committee Chair (andrew.morgan@utoronto.ca)

Matt Napier – Elected committee member (m_napes@hotmail.com)

Naureen Shameem – Chief Returning Officer (aerinsol@hotmail.com)

Adam Wakefield – Elected committee member (fufb@hotmail.com)

Activities of the Committee

            The Web Election Committee initially discussed the issue via e-mail, and then followed up by a meeting in person on January 9, 2002.  Jim Delaney, Assistant Director of Student Affairs at the University of Toronto, was contacted concerning hosting the elections on ROSI.  Gilbert Verghese, Computer Services Coordinator at Trinity College was contact concerning hosting the elections on a Trinity computer.  Dean Bruce Bowden was contacted in his capacity as Trinity Registrar to assess support from his office for hosting the elections on ROSI.  Previous discussions on the SMRT e-mail list provided a good background from Ashley Morton concerning the University of Toronto Engineering Society (EngSoc) method of voting by e-mail.

Identified Problems with Paper Ballots

The impetus to investigate web elections comes from the follow problems identified with the current system of using paper ballots:

  • Allegations that the ballot boxes were stuffed with fake ballots before voting began.
  • Allegations that the ballot boxes were stuffed throughout the day as voting occurred.
  • Allegations that some ballots were accidentally lost during the counting process due to their small size.
  • The extended period of time it took to count the ballots, usually 1 hour with 4-8 people present.
  • Low turnout rate among non-resident students.
  • Low turnout rate among resident students, though better than the non-resident turnout rate.
  • High time commitment required on behalf of the Chief Returning Officer, Deputy Returning Officer, and their designates.  The elections consisted of three or four weeks of voting, one day per week, with the polling both being open from 11:00 a.m. to 4:00 p.m.

ROSI Option

            One option was to ask the Student Information Systems (SIS) (www.sis.utoronto.ca), the department at the University of Toronto responsible for the ROSI (www.rosi.utoronto.ca) to host the elections for Trinity.

Pros:

  • The module to run elections is already in place in this system, due to running the SAC and GC elections.
  • Student Affairs of the University might pick up the costs for the development of a module just for Trinity.
  • Everyone, res and non-res would have access to voting.
  • The CRO does not have to devote an entire day to sitting by the ballot box.
  • ROSI is the most secure option.

 

Cons:

  • ROSI’s current system does not have the capability to do preferential balloting, and the time and effort that it would take to develop a program that could do this, would be equal to the amount of time that it took them to form the first program.
  • The data entry for this option would be very difficult and time consuming, and could not be taken on by a student, since student are allowed to have nothing other then a web interface with ROSI.  Therefore, all of the data entry and results would have to come through the Registrar office – thus duplication a portion of the CRO’s job.
  • ROSI hasn’t decided whether or not they are in the elections business.  We could make a formal request that they decide this, but even if they make that decision, we would not have everything in place for the March 2002 election, the earliest would for the March 2003 election, which the winners holding office in the 2003/2004 academic year.
  • It is easy to lock out students from ROSI, thus making it impossible to vote, by using their student number and logging in three times with the wrong password.
  • There could be no scrutinizers.
  • Trinity would have to provide ROSI with eligibility lists with student’s year of entry, res/non-res status, humanities/social sciences/science status.
  • In discussions with Dean Bowden in his capacity as Trinity Registrar he has expressed his concern that a ROSI option might take require too much of a time commitment from his office.

 

E-mail Concerning ROSI Option:

 

From: Jim Delaney [mailto:jim.delaney@utoronto.ca]

Sent: November 22, 2001 11:04 AM

To: Andrew Morgan

Cc: Rick Hayward; Kirstin Cirulis; Susan Addario; Paul Oleskevych

Subject: Re: Fwd: Online Voting for Trinity

 

 

Hi Andrew,

 

Student Information Systems (SIS) forwarded your message to me.

 

I certainly imagine a day when all student elections could occur

on-line (perhaps all at the same time) -- but it's going to take some

time for us to get there.

 

At present, while the SAC and GC elections are run within ROSI, the

maintenance and data related tasks (such as loading candidate data)

are handled outside of Student Information Systems.  The Governing

Council secretariat handles the GC elections and Student Affairs

handles the SAC elections.  We even print the results for SAC locally.

 

There are a number of issues to consider here:

 

1) Development Cost.  The core election module exists -- but there

will be a cost to adapt the SAC or GC modules for other elections.

Eligibility to vote for the SAC elections is based upon payment of

the SAC fee while eligibility to vote for GC is based upon student

status (part-time/full-time) in combination with an association with

categories of academic divisions in ROSI.  Trinity College Meeting

elections would presumably be based upon association with Trinity or

payment of the student society fee.  This may sound like a trivial

modification -- but there are complexities to this that require

considerable testing for each different voter eligibility requirement.

 

2) Development Time, ROSI Priorities and SIS Staff Resources --

depending upon the nature of the work.  There is a considerable

amount of ongoing development work in SIS on ROSI in general.  A new

election module would need to compete with other priorities already

in queue.  You might recall that the delay in the SAC elections last

spring related largely to availability of SIS staff to complete the

work.

 

3) Support Staff Availability.  Since all the maintenance is done

outside of SIS, it means that staff resources somewhere else within

the University must be devoted to this.  Because of a variety of

considerations (e.g. training, understanding of the module), SIS has

decided that Student Affairs would need to do this for all web based

elections for student societies.  SIS sounded pretty firm about this

when we met recently -- but at an absolute minimum, it would have to

be a University staff member who maintains the data since it requires

staff access to ROSI.

 

4) Actual Election Costs.  Your requests for estimates assume that

this is a service that can simply be purchased.  The reality is that

in the current set-up, only the development costs would need to be

covered.  Student Affairs would be incurring the actual maintenance

costs since our staff do the work (and, as you know, we do not bill

out for services).

 

5) Priorities for Election Development.  This is a relatively new

feature of ROSI.  Frankly, I would like to see how it goes this year

(running GC and SAC at the same time) before we start adding more

elections.  In addition, while the GSU has formally indicated that

they have no interest in web-based voting, we would also need to

accommodate APUS (and the remote possibility of the GSU) before we

start adding new elections.

 

The bottom line is that I don't think this will be possible for

2001-02.  Even if we had Student Affairs staff available, I can't see

this moving up the ROSI priority list in time.  Remember that ROSI

is, primarily, an academic registration and student records system --

academic priorities need to come first.

 

Nonetheless, it might be possible for future years.  If you want to

start thinking about 2002-03, we could map out the steps now.

 

Paul Oleskevych in our office does the actual maintenance work for

the SAC elections.  If you want to get together on this, Paul should

join us so that he can give you a clearer understanding of the work

that occurs at this end for the SAC elections.

 

You didn't mention whether or not there is support among Trinity

administrators for this.  At the very least, it would be good to have

Bruce Bowden's support in principle (since registrars have a key

relationship with SIS with respect to ROSI enhancements).

 

Jim

Trinity Server Option

The Trinity Bursar’s lodge would give out one random number to every Trin. Student that went into them, and this number would be their log in and password to the voting site.  There could either be one number for all elections, or one for every week.  We would need to find a programmer to design the database that this fed into.

 

Pros:

  • It is an internal Trin system so could be made to meet with our elections rules.
  • It is relatively inexpensive

 

Cons:

  • Every student that wanted to vote would still have to come into Trinity and physically pick up his or her number.
  • It is recreating a smaller version of ROSI, which seems redundant.
  • It would be really hard to program in all the exclusion and eligibility conditions that exist in our elections.
  • The student number of students who voted would become more visible.
  • Elections are too small to really legitimize this option.
  • There could be no scrutinizers without allowing them to see how every single Trin. Student voted.
  • The student who maintained the system would graduate, risking the possibility that a replacement programmer could not be found to update the program.
  • All of the trust on the integrity of the system would rest with a student, in the same way that it does now with paper ballots.
  • It would be difficult to find a student who was willing to program this solution.

E-Mail Concerning Trinity Option

From: Gilbert Verghese [mailto:gv@trinity.utoronto.ca]

Sent: November 22, 2001 1:09 AM

To: Stephen Doma; Andrew Morgan

Subject: Re: Online Voting for Trinity

 

 

If you look at the head's package you'll see that the majority of students

use non-trin email accounts. How would you guarantee one vote per person and

how would you authenticate voter identity?

 

One way would be to generate a voting code (ballot) for each student like we

do for account creation codes and mail each individual their  code. A code

can be used only once. You could use php and a mysql table to keep track of

who has voted and how. Do you know php and mysql? If so it's a few hours of

programming and testing. The expense is in sending out the ballots. I

wouldn't use email because people may know other people's passwords. Maybe

you could just leave the ballots with people's names on them with the

Porters, if you trust them.

 

Gilbert

E-mail Option

This is the system that the Engineers use.  Every engineer that wants to vote in their elections sends an email to the CRO, at a special CRO account, using their ecf.utoronto.ca accounts – which they have to get when the sign up for their program.  The CRO then responds to everyone email, with just the contents of the original text, to ensure that people were not fake voting.  This option could be made into Trin.’s using either everyone’s Trinity account, or their utoronto.ca account.  This option assumes that everyone has a secure email site, and that they check it regularly.

 

Pros:

  • It is a little bit like the uber-ballot that was used for the last two weeks of elections last year.
  • Non-res could vote easily.
  • If people didn’t have either a Trinity or utoronto account, then we could use the email account that people placed in the Head’s Package.
  • We could also get Jennifer Hall to do a ROSI pull (where she finds the email address that all students are using for ROSI) and then the ballots could be sent there.  This has the added advantage of making people update their information on ROSI

 

Cons:

  • People could stack that Head’s Package with fake names to allow for more voting opportunities.
  • Hotmail and other web-based email account are a problem, because there is no way to ensure that the student who opened it, is the person that they claim to be.
  • The Engineers aren’t quite as apathetic as Trinity students are, so they vote more often, and take the time to pay attention to their ecf accounts.
  • Does not allow for scrutinizers unless scrutinizers are allowed to see all of the ballots, in which case all anonymity is lost.
  • Does not allow for anonymous voting.
  • Have to create the database to implement the vote tallying and eligibility checks.
  • The voters themselves would have to decide their eligibility and the CRO would have to check everyone.
  • It means a lot more man-hours for the CRO, but on a more flexible schedule.

 

E-mail Concerning E-mail Option:

From:  "Ashley Morton" <ashleyjmorton@hotmail.com>

To: smrt@yahoogroups.com

http://groups.yahoo.com/group/smrt/message/2898

Date:  Sun Jul 22, 2001  12:50 am

Subject:  How an election can work.

 

Hi.

 

 

I thought that I might venture into the fray of election discussion. My primary contribution will be a description of what works in Engineering, and why I think that it works, but first:

 

-There's not a snowball's chance in Hell that ROSI would do the Trin elections. They are, in general, throroughly incompetent, and actually, we in Engineering contacted them about it last year (we also do preferential voting, but we only have one week's worth). They laughed in our face, and made some comment to the effect of not having enough time to make sure that the marks subprogram always worked, and having the SAC one shoved down their throat.

 

A for the Engineering election:

 

Our constituency is larger, but not by an order of magnitude, but has many of the same features:

-A small group of people who are very involved, though clearly not always in agreement.

-A significant portion of the constituency who never pass through the building (students who are doing an internship year, who may be as near as College & University, or as far away as Johannesburg)

-A non-participatory (at least in the "standard" ways) group who often gripe about paying student fees and not being really represented.

 

Anyways, here's how we run our (one week only) election.

 

-There is only one ballot box, in the central cafeteria in Engineering. Anyone who can reasonably be expected to pass through the Engineering section of campus (ie is not on an internship year) must vote there if they wish to vote.

-Students who are on internship years must send an email to two addresses (one which the CRO holds the password for, and one which the registrar holds the password for), sometime after the first time the poll is open, and sometime before it closes for the last time. This means that they may vote overnight between voting days, but can't vote before campaigning is finished, or anything. They send their name and student number in the subject line, and then in the body, only their votes. An email is sent out to every one of them with the template for this on it (basically a ballot). They must respond from the email account that the CRO's outgoing email was sent to. If they don't it is automatically disqualified.

-If there is ever a situation in which there is less than two poll clerks, the poll is closed. There must be two little initials on the bottom corner of every ballot, or it is not valid.

-Campaigning is allowed, but on a very limited scale. Candidates may not take office (the prime indicator being the set of keys to the physical office) until all remnants of campaigning are removed. The numbers of posters and leaflets are proscribed (100 each, I believe, but that would obviously be a smaller number in Trin's case) Candidates may also speak in public (we have classes which are almost exclusively engineers, so it works well, but dinner, etc. would work), but obviously are then subject to rotten fruit (one guy actually had a banana thrown at him this year, because he had interrupted a class).

-There is a CRO, who is elected, but as it is a year-long job, and there are people looing over your shoulder at every step, very few people want it.

-Vote counting: scrutineers and returning officers are allowed into a room, and first all email votes are counted as such: the two email accounts are opened in the same room, and are compared. All people who emailed outside the time deadline are eliminated. All people who voted in person (because internship students may vote at the box if they wish) as well as email voted are eliminated. Then all the emails are printed. All of the headers are physically ripped off the papers, and the papers are shuffled. From there, the counting is pretty simple. We developed a good program this year, using excel to do the preferential switching of votes.

 

Oh yeah, and we had a 25.6% turnout. That's over 1200 votes.

 

We counted them all for 5 positions in just under 7 hours. 6.5 of those hours were spent just opening the ballots and reading them. only about half an hour was spent on all the formalities of the email ballots, and the switching of preferential votes around.

 

I know that it's not 100% portable, but I really think that the system works. What's the voter turnout for a college (not SAC) election, even H of C? 5%? 10%?

 

I think that the two basic things that our system has over Trin's are campaigning (four of the five positions were filled by non-clique people, yet people who had impressive credentials), and the basic belief by most people that it is fair and safe. I know that I don't trust the Trin system, because it just doesn't have the checks and balances (two initials on the ballot, voting booths, etc.) I wouldn't trust the Trin system as it is now. Not that I'm going to have a shot, now, because I got rejected for res anyway.

 

Cheers,

 

Ashley

 

Swipe Card Verification

The CRO would sit at a computer in the Buttery with a swipe card verifier.  Students would swipe their T-Cards as they vote in person with paper ballots. The computer would have to be secure, but we could use a Trinity lock box, which apparently there are a few around college.

Pro:

  • This option solves the problem around the CRO have exclusive access to the ballot box for an entire day, as other people could fill in for the CRO.
  • This allows for a more verification of those who actually voted

Cons:

  • This option could not allow for scrutinizers, unless they are allowed to see the list of students that voted.
  • Does not solve the non-res problem.
  • Expensive.
  • Requires someone to program a voter verification program, probably in MS Access.

Corporate Options

            There are a number of corporations that will host Internet voting.  It is expected that their prices would be far beyond Trinity’s budget.  These corporations are:

 

http://www.safevote.com/

http://www.votehere.net/

http://www.election.com/

General Thoughts on Internet voting

 After discussing all the options, we noticed that the same problems were coming up:

  • It is very difficult to have scrutinizers without sacrificing voter privacy
  • None of the present options allows for preferential voting, without a lot of extra man-hours, and due to the magnitude of some of the elections that we are holding, preferential balloting is really Trinity’s only option.
  • Our rule of no campaigning doesn’t work when we go to the internet, because people do not have a chance to see the people that they are voting for, and the non- res. would have never have heard of most of the candidates.  So we could allow for Internet campaigning only, but that would turn elections into a race to see who could find the largest listserv.
  • With Internet voting it is very hard to make sure that listservs aren’t being sold and being used to campaign with, if we don’t allow campaign., and since the average success rate of a listserv mail out is 10-25% - this is enough to sway any of the Trinity elections.
  • All of the Internet options leave the election more open to tampering from all sides.
  • It was generally thought that if a non-res. could come out to vote for an election, then they were showing that they had no interest in voting in the first place.  This was raised in the sense of Federal Elections, where if you don’t go out to vote – then you obviously didn’t want to.  Also, the Trinity Electoral Policy does allow for proxy voting, so if they couldn’t make it the day of elections, they could find the CRO, and vote earlier.

 

 

Research on Internet Voting

Internet Voting Technology Alliance

Group to set standards for Internet Voting

http://www.ivta.org/

 

SecurePoll

Clearinghouse of Internet voting information

http://www.securepoll.com/

 

The Bell

Bi-Monthly Publication on Privacy, Security and Technology in Internet Voting

http://www.thebell.net/

16 Online Voting System Requirements

http://www.thebell.net/papers/vote-req.pdf

 

Caltech-MIT Voting Technology Project

http://www.vote.caltech.edu/

 

GNU Free Internet Voting Software

Non-preferential, Java based voting software available for free

http://www.free-project.org/

 

University of Toronto Governing Council Web Election Student Survey

Survey of 1210 U of T students on their views towards Web Elections

http://www.utoronto.ca/govcncl/bac/studentvoting2001.pdf

Suggestions for Amendments to the Electoral Rules

  • Every year after elections, the CRO and DRO prepare a report about how the elections went, and how they should be changed for the following year.
  • Changed the ballot box into a real ballot box, where either the H of C, or a member of the administration has the key, and only unlocks the box at the end of the day, so that the CRO can not stuff the box before the elections start, and can not tamper with the box during the voting hours.
  • A re-election should be called if the miscount is greater then the margin of victory.
  • The scrutinizers protocols needs to be written into the Electoral rules.

Recommendation

            The Web Election Committee recommends that it pursue the ROSI option for the March 2003 election.

Final Action

            On January 30, 2002, the Trinity Joint College Meeting (JCM) voted to reject the recommendation of the Web Election Committee, therefore ending the Web Election Committee’s activities.