MOCK ELECTIONS VOTING DESIGN CHALLENGE

Design Challenge: Design a software program and/or electronic voting system so that students in Allegheny County can vote electronically in their school Mock Elections on machines that you have in your schools.

Your entry should be able to allow high school students to vote in the races which will be on the ballot in the General Election of 2010:
• Pennsylvania Governor and also Lieutenant Governor
• U.S. Senate (one of two seats)
• U.S. House of Representatives
• Pennsylvania House of Representatives
• Pennsylvania Senate (even-numbered districts)

Contest requirements:
• Students should put together a design. They should develop and test a prototype of this design.
• Students should put together a report/presentation (e.g. in PowerPoint) about their ideas, design considerations, and their prototype.

Entries will be judged in May. Judges will include civic leaders, business and technology leaders, representatives from the Allegheny County Department of Elections, experts from Carnegie Mellon University and from the University of Pittsburgh. Prizes will be awarded. Names of the winning schools (and students, with parental permission) will be publicized.

In the fall of 2010, the winning software program/system or the best elements of systems will be incorporated into the first Allegheny County-wide Mock Elections to be conducted in your and other area high schools.

This contest is being conducted by the League of Women Voters of Greater Pittsburgh in collaboration with Greater Pittsburgh Student Voices, under the auspices of the federal government’s U.S. Election Assistance Commission (EAC) Mock Election Program.*

Resources
Students can watch the entertaining cartoon video that demonstrates the electronic voting machine used in Allegheny County, the ES&S iVotronic. The video can be found on the Votes PA website,www.votespa.com, specifically at http://www.votespa.com/portal/server.pt/community/how_to_vote_/13515/voting_system_demos

Students should also access the League of Women Voters of Greater Pittsburgh’s website www.palwv.org/pittsburgh/. First click on the New Voting Machines icon in the right column to access two additional demos of the ES&S iVotronic voting machines.

Additional information that is part of your information package
• Deliverables (see below)
• Judging Criteria (see below)
• How Elections Work, a brief overview and additional resources
• The “17 Points” – Pennsylvania’s requirements for electronic voting systems

This information can also be reached from the “Mock Elections Contest” icon in the right column of the League of Women Voters of Greater Pittsburgh’s website. More information may be added to that link in March and April.

You will also be able to send any questions you have to the technical assistance person for the contest, whose email will be listed on the page. There will also be FAQs.

Other things you should look at on the League of Women Voters of Greater Pittsburgh’s website:
• Facts for Citizens – an electronic version of the annual brochure listing all elected offices that Allegheny County residents vote on, the current elected leaders contact information and salaries, and which offices are up for election each year. There’s also a link to that page at the League website where you can click on “OUR GOVERNMENT in the left column, then “Facts for Citizens.”
• Smart Voter – a website which provides information about the candidates, customized according to your address. We want to encourage high school students who vote in the 2010 Allegheny County-wide Mock Elections to use Smart Voter as an informational resource so that students know something about the candidates before they vote in the Mock Elections. There’s also a link (in right column) from League website.

Deliverables
A goal of each group should be to deliver the following materials at the completion of the project. We do not expect that each submission will include all of these elements. Student teams may, for example, submit a researched design report describing a design or design criteria based upon surveys and analysis.

Demonstration System
The demonstration system should be the voting system developed by the student group. Incomplete systems or demonstration systems (mock-ups) will also be accepted and should be documented thoroughly describing those portions of the system not implemented.

Materials to be submitted:
• Sourcecode and compiled binaries for the demonstration system.
• A list of specifications for all required hardware.
• A list of necessary supporting software including third-party libraries and directions to obtain them.
• Deployment instructions including:

Report
Student teams should produce a shared report defining their project goals, documenting their work, analyzing the success of their efforts and identifying outstanding issues that they did not have time or resources to address. The students should also make clear what tradeoffs were taken in system development and how those tradeoffs affected their work.

Key points to be included:
• The design of your system including a high-level outline.
• The members of your team and the process by which they produced the system.
• Any other activities (e.g. student survey) your team employed during the design process.
• An assessment of your system responding to the list of criteria. How well your system meets the desired criteria (see the questions to consider in the sections below) and what changes you would make.
• Any known problems with your system.
• Any changes you would make to future versions of your system.
• A comparison between your system and the existing iVotronic as used in Allegheny County.

Project Judging Criteria
Student projects will be judged according to the following criteria. We do not expect that each submission will meet all of these criteria. The goal is for students to understand these requirements of a good voting system, to think about how they can be met, and to implement as many of them as possible.

As this is a design project these criteria are not listed with numerical values nor will students be given a single "grade.” Rather the student teams should attempt to address these criteria and, in their report, highlight how they meet or do not meet the criteria. As with any real-world design problem the criteria are described at a necessarily high level. It is up to the student teams to decide what the criteria mean for their project and how the criteria should be met. Some criteria may conflict, requiring the teams to make tradeoffs between, for example, usability and security. The student teams should for identify these tradeoffs and explain the decisions that they make in their final report.

Security
In order to guarantee the security of elections a voting system needs to accurately record and tabulate each vote without permitting votes to be altered by outside attackers or corrupt officials. It also needs to protect against vote-selling and voter intimidation by guaranteeing that votes are private and that no attacker (whether outsider or corrupt official) can determine how each voter voted. Security is addressed in the books by Schneier and Campbell mentioned under Resources in file file on How Elections Work. Questions to consider:
• How secure is the system against malicious attacks including attempts to alter or remove votes, replace essential hardware or software, or violate voter privacy?
• What steps have you taken to ensure that the system is secure and voter privacy is guaranteed?
• What steps would you take in future versions of the system?

Auditability
Post-election audits and recounts are an essential feature of well-run elections. Audits enable voters to guarantee that an election was run correctly and that the votes were counted accurately. Questions to consider:
• Does your system permit post-election audits?
• If so, what kinds of election problems can be identified by those audits?
• What kinds of election problems would be missed by your audits?
• What improvements would you make to future versions of the system?

Reliability
A voting system, like others must operate reliably and tabulate votes correctly even when voters make entries in unexpected orders, select incorrect combinations, and so on. Questions to consider:
• Does the system cast and count votes accurately?
• How does the system tabulate in the face of overvotes (selection of too many candidates in a race)?
• How does the system tabulate in the face of undervotes (selection of too few candidates in a race)?
• Does the system properly record canceled votes?
• What improvements would you make in the reliability of future systems?

Usability
A voting system must be "usable" both for voters and for election workers (pollworkers, & election officials) including setup, takedown, etc. Questions to consider:
• Is the system usable for voters? How did you test this?
• Is the system usable for election workers? How did you test this?
• What usability improvements would you make in future versions?

Accessibility
Is the system accessible for voters with visual limitations, physical impairments, or other disabilities? Questions to consider:
• Can voters with motor impairments use the system? How did you test this?
• Can voters with visual impairments use the system? How did you test this?
• Does the system support languages other than English?
• What improvements would you make in future versions of the system?

Legal Requirements
Pennsylvania law describes a series of legal requirements for electronic voting systems including the 17 points (summarized in the instructional materials). Questions to consider:
• Which of the required features described in the law does your voting machine meet such as implementing the Pennsylvania Method and providing for a paper audit?
• For those points on which your system is deficient, what improvements would you make?