What happens when the network or the system fails?

For the My Vote Forward educational websites, a network or server failure means a page does not load; nothing official is lost, because nothing official happens there. For the demo, a failure may lose an unsaved simulated draft. For any future official vote, failure is a serious design requirement: voting must remain possible through other channels, no one may be counted twice across channels, and there must be durable records that survive an outage. The framework does not claim to have a design that meets those needs today.

The objection in its strongest form

The objection is that every networked system fails eventually, and a civic system fails at the worst time. Outages cluster around peak demand, which for civic participation means deadlines and election days. Attackers know this and time denial-of-service attacks accordingly. Phones run out of battery, apps fail to update, home internet drops, and servers misconfigure under load. A system that depends on a network makes participation conditional on infrastructure that ordinary people do not control.

The strongest version adds that failures are not neutral. Outages hit some people harder than others: those with older devices, rural connections, or no backup option. A partial failure can be worse than a total one, because it changes who participates without anyone noticing. And after a failure, the public argument over what happened can do more damage than the outage itself, especially if officials and vendors give different accounts. A technically minor failure in a high-stakes setting can permanently damage trust in a whole method.

Why the objection matters

The objection matters for My Vote Forward because its long-term ambition includes authorized private voting, and any voting design must answer what happens when it breaks. It also matters for the present framework: published releases, scheduled times, and saved priorities all depend on servers. A framework that treats failure as an afterthought would produce rules that work only on a good day.

Defined terms

• Availability: the ability of a system to serve people when they need it.
• Continuity plan: the procedures that keep a process working when a component fails.
• Durable record: a record of a vote or action that survives the failure of the system that created it, such as a voter-verified paper ballot.
• Provisional ballot: in U.S. federal elections, a ballot cast by a person whose eligibility cannot be confirmed at the polling place, counted only after verification.
• Double counting: counting the same person more than once across channels, such as online and in person.

Evidence

Paper as the record that survives software. In 2018 the National Academies recommended that “all local, state, and federal elections should be conducted using human-readable paper ballots by the 2020 presidential election,” that marked ballots “should not be returned over the Internet or any network connected to it,” and that states mandate risk-limiting audits before certification.⁠¹ Lindeman and Stark explain the reasoning: “Computer software cannot be guaranteed to be perfect or secure,” so voting systems should be software-independent, and a well-curated audit trail provides that independence.⁠²

A legal fallback for eligibility problems, United States. Federal law provides that a person who declares they are a registered, eligible voter but is not on the polling place list, or is told they are ineligible, “shall be permitted to cast a provisional ballot”.⁠³ It also provides that a person who votes only because a court or other order extended polling hours “may only vote in that election by casting a provisional ballot,” and that such ballots be kept separate.⁠³ Provisional ballots are not a network-failure mechanism, but they show the principle: when the system cannot confirm something at the moment of voting, the person still votes, and the question is resolved later from a durable record.

Federal guidance on electronic return. CISA, the EAC, the FBI, and NIST issued guidance in 2020, reissued publicly in 2024 as “operative,” on the risks of electronic ballot delivery, marking, and return.⁠⁴ Verified Voting reports that the agencies found electronic return “faces significant security risks to the confidentiality, integrity, and availability of voted ballots,” risks that can “ultimately affect the tabulation and results and can occur at scale”.⁠⁵ Availability is named alongside confidentiality and integrity.

A failure in practice: the 2020 Iowa caucuses. The Iowa Democratic Party’s 2020 caucuses used a smartphone app to report results, and results were delayed. A review commissioned by the state party, released in December 2020, found that “The reporting app performed as intended and was not hacked or compromised,” and attributed the problems to “the late development of the delegate-win reporting software” and “multiple procedural clashes between the state and national parties”; it also cited the party headquarters’ “inability to handle high call volumes”.⁠⁶ The caucus was a party process, not a government election, and this page relies on news reporting of the review rather than the review itself. It is cited because it shows how late software, a fallback channel that could not absorb the load, and disputes between organizations can combine in one night.

How comparable systems have handled it

Estonia keeps paper as the final word. Estonia lets voters vote online during advance voting, and states that from 2021 voters can change their i-vote by voting with a paper ballot at a polling place on election day.⁠⁷ A paper vote overrides an i-vote.⁠⁷ Whatever the reason a voter uses it, the effect is that an in-person paper channel remains available alongside the online one.

International standards require an in-person option. The Venice Commission’s code states that “voters should always have the possibility of voting in a polling station,” and that electronic voting “should be used only if it is safe and reliable”.⁠⁸

Switzerland stops and redesigns. Swiss e-voting has been offered by 15 cantons to a limited part of their electorates in over 300 trials since 2004, under a principle of “security before speed”.⁠⁹ In 2019, flaws discovered in the system sparked a political debate; Swiss Post halted development of a project in July 2019, and the government dropped e-voting plans for the time being.⁠¹⁰ Several cantons are now running trials again.⁠⁹ Halting a channel when it cannot be trusted is itself a continuity decision: other channels carried the vote.

Competing interpretations

One interpretation holds that resilience is an engineering problem with known solutions: redundant servers, offline modes, load testing, and staged rollouts. On this view, failures like Iowa’s reflect rushed deployment, not an inherent limit of networked systems.

A second interpretation holds that networked voting adds failure modes that paper and in-person voting do not have, and that the only robust design keeps a non-networked channel and a durable paper record as the authority. The National Academies’ recommendations and Estonia’s paper override are consistent with this view.⁠^1,7

A third interpretation distinguishes stakes. For non-binding priorities and opinions, occasional failure is tolerable if it is disclosed and nothing is silently lost. For official votes, the tolerance is near zero, and the design must assume failure.

What the framework answers

My Vote Forward’s rules are:

• The educational websites and demo are not official channels; a failure there loses no official vote (see status).
• Any future official use would need other voting channels, prevention of double counting across every channel, and durable records that survive a system outage (see security and identity and registration).
• An in-person alternative remains essential; any remote channel would be an addition, not a replacement (see intimidation).
• Published releases are scheduled on the server, published as the same immutable version to everyone, and corrected by new versions rather than silent edits, so a failure during release cannot produce different versions for different readers (see published releases).
• The project’s build specification requires backups with a restoration check and incident and rollback runbooks for the websites; whether each is implemented is reported on the status page, not assumed (see security).

Where the objection still wins

The objection wins for any future official use. The framework has no continuity design, no tested offline mode, no load testing at election scale, and no mechanism for preventing double counting across channels. It has not been tested under a real failure. Even for the current demo, the framework cannot guarantee that a draft survives a dropped connection. And it cannot prevent a future failure from damaging trust in the broader idea, whatever the technical cause.

Unresolved questions

• What durable record would a future remote channel produce, and who would hold it?
• How should a future system decide, during an outage, whether to extend a deadline, and who has that authority?
• How can a system detect that a partial failure changed who participated?
• What load and failure testing would an authority require before any pilot?

Related

• Security
• Audits and verification
• Published releases
• Is this an official voting service?
• Can a household coerce a remote voter?
• Hard questions