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.
Postscript (December 22, 2025): NPR’s All Things Considered aired an interview with Bradley Tusk that discussed this blog post. Mr. Tusk responded to my three numbered points without really addressing any of them:
- My point: Even when given a way to check their computer-generated ballot, we know that most voters won’t do so. His response: “The first was ballot checks, and that is voters going back and looking at a PDF of their ballot to ensure that it’s what they intended to do. We’ve built a system to do that. We give you a code, you put it into a different device, a PDF of your ballot comes up.” That is, he gives voters a way to check, but he doesn’t at all address the point that most voters won’t use that method, or any method.
- My point: Lack of a dispute resolution protocol means that if many voters during an election claim to election officials that they caught the computer cheating, there’s no method by which those officials can do something about it. His response: “His second point was the lack of a dispute resolution protocol. And the reason why that’s not in the tech that we have built is every jurisdiction has totally different views as to how they want to handle that. So whatever approach, you know, any specific city, county, state wants to use, that could then be built by whatever vendor they’re working with into the system.” But since there’s no known method that works (and this has been the problem with all E2E-VIV methods for many years now), you can’t just say “any jurisdiction can choose whatever method they prefer.” There’s nothing to choose from.
- Regarding point three, he says: “And then his third point was just the risk of malware. And he’s right. That is a risk that exists every time that you go on the internet, every time you use your phone, every time you use your iPad, no matter what. Things go wrong at polling places all of the time. The volunteers don’t show up. Someone pulls the fire alarm. And then with mail-in ballots, trucks get lost. Ballots get lost. Crates get lost. So, you know, to say that you need this absolute standard of perfection for mobile voting when the real ways that we vote today are far below that doesn’t make sense.” This response evades some key points. (A) In most of the things that matter that we do on the internet, such as banking and credit card transactions, there’s a dispute resolution protocol. Individual transactions are traceable; for many e-checks and for many credit-card transactions, the bank checks with you by SMS or e-mail before putting the transaction through; and (by law) there are established dispute-resolution protocols. For e-voting, none of that works, and it can’t be solved just by passing a law. (B) “Things go wrong [with polling places and mail-in ballots].” This whataboutism ignores that e-voting can be hacked invisibly at huge scales from a single remote location, whereas these local polling-place and mail-in ballot problems–which do indeed occur–are usually recoverable, measurable, and accountable.
Mr. Tusk does not address my (unnumbered) point that the checking protocol seems to allow the voter to prove how they voted, which is a standard no-no in any e-voting system (because it allows the voter to sell their vote over the internet).
Leave a Reply