Mobile Voting Project’s vote-by-smartphone has real security gaps

Bradley Tusk has been pushing the concept of “vote by phone.”    Most recently his “Mobile Voting Foundation” put out a press release touting something called “VoteSecure”, claiming that “secure and verifiable mobile voting is within reach.”  Based on my analysis of VoteSecure, I can say that secure and verifiable mobile voting is NOT  within reach.

It’s well known that conventional internet voting (including from smartphones) is fundamentally insecure; fraudulent software in the server could change votes, and malware in the voter’s own phone or computer could also change votes before they’re transmitted (while misleadingly displaying the voter’s original choices in the voter’s app).

In an attempt to address this fundamental insecurity, Mr. Tusk has funded a company called Free & Fair to develop a protocol called by which voters could verify that their votes got counted properly.  Their so-called “VoteSecure” is a form of “E2E-VIV”, or “End-to-End Verified Internet Voting”, a class of protocols that researchers have been studying for many years.

Unfortunately, all known E2E-VIV methods, including VoteSecure, suffer from gaps and impracticalities that make them too insecure for use in public elections.  In this article I will pinpoint just a few issues.  I base my analysis on the press release of November 14, 2025, and on Free & Fair’s own “Threat Model” analysis  and their FAQ. 

The goal of an E2E-VIV protocol is to let the voter to check that their vote is included in a public list of ballots.  But if this were done in the most straightforward way—like include the voter’s name or ID-number in a public cast-vote record—then voter privacy (the secret ballot) would be lost.  Any E2E-VIV system needs way for the voter to check their ballot without then being able to prove to someone else how they voted (otherwise voters could sell their votes, or be coerced to vote a certain way). Most E2E-VIV systems use the “Benaloh challenge“; but VoteSecure does it a different way. And really, in all the documents and analysis they have published, they have no explanation of how their “check” protocol satisfies the most basic requirement of E2E-VIV: voter can have confidence that their ballot is cast correctly, without being able to prove how they voted.

In addition to that omission, all E2E-VIV protocols have suffered from at least three big problems:

• Voters need to actively participate in checking, but we know (from human-factors studies) that the vast majority of voters won’t perform even the simplest of checking protocols.
• Lack of a dispute resolution protocol.  If some voters do detect that the system has cheated them, what can they do about it?  Without a dispute resolution protocol, the answer is, Nothing.
• Malware in the user’s computer (or smartphone) can corrupt both the voting app and the checking app.  So you might do the “Check”, and it could falsely report that everything’s fine.

VoteSecure suffers from all three of these problems. 

First, voters won’t participate in checking.  Even in present-day polling places, in those jurisdictions where voters use a touchscreen (BMD, Ballot-Marking Device) to indicate their votes for printing out onto a paper ballot, we know that 93% of voters don’t look at that paper carefully enough to notice whether a vote was (fraudulently) changed.  If only 7% of voter won’t even execute a “Check” protocol that’s as simple as “look at the paper printout”, then how many will execute a more complicated computer protocol that requires them to use at least two different computers?

Second, there’s no dispute resolution protocol.  During some election, if many voters report to election officials that they’ve done the “Check” and found that the system is cheating, what’s the election official supposed to do?  Cancel the election and call for a do-over?   But if the Secretary of State invalidates elections whenever lots of voters make such a claim, then it’s obvious that a malicious group of voters could interfere with elections this way.  Page 30 of Free & Fair’s own Threat Model document discusses this case, and concludes that they have no solution to this problem; it’s “Out of Scope” for their solution.

Third, the designers of this system make real efforts to defend against hacked servers, but pay very little attention to the possibility that the voter’s phone will be hacked.  If the phone is hacked, then not only can the voting app be made to cheat, but the checking app can cheat in concert with the voting app.  The Threat Model refers to this possibility in a few places:

• On page 4, they suggest “there may be multiple independent ballot check applications”; do they really expect the voter to go to an entirely different computer to perform the check?  That’s far too much to expect.
• On page 42 they discuss “AATK4: Compromised user device”, but unlike almost all the other attacks listed they do not even attempt to discuss mitigations of this attack.
• On page 30 and 33 they discuss “VD”, short for “Voter Device”, including the possibility that the voter’s smartphone has been hacked.  In both places they write “Out of Scope”, meaning, they have no solution for this problem.

Finally, they make no claim that this system is ready for use.  It’s not a vote-by-phone system that anyone could adopt now; it’s not even a voting system under development; “Free & Fair is not developing such a system, but only the cryptographic core library.” All the hype from Mobile Voting about their pilot projects, past and current, is about systems that use plain old unverifiable internet voting.

In conclusion, this “VoteSecure” is insecure in some of the most traditional ways that Internet Voting has always been insecure:  If malware infects the voter’s computer or phone, then the voter can vote for candidate Smith, and the software can transmit a vote for candidate Jones, and there’s little the voter, or an election official, can do about it.