> The clients do not interact with the blockchain directly, so there is no blockchain verification code in the client.
So if all client requests are routed through the same centralized API endpoint before hitting the blockchain, nor validated after the fact, whats the point of the blockchain? Just some public "ledger" of what the server ultimately sends out?
Ideally, at a minimum, you would be given a token for your vote which you can then follow up and see it on the ledger. Even if you don't get to wait for 'confirmation', it's still a public signal that something is not right.
The honest answer is that I have no idea. In the version we reverse engineered, there's no proof of inclusion of any of the data in the blockchain in the client, and the receipt system was via a PDF. The vote selections (ballot?) are also never signed by the client.
It's also worth noting that, according to the ToB article, the backend blockchain is a permissioned hyperledger instance, which runs PBFT[1] rather than proof of work. PBFT is controllable with roughly 1/3 of the network, 100% of which has been controlled by the company.
Is there any technical/security benefit at all to private blockchains? Or even more generously, lightly-mined public blockchains? It seems that in either of those scenarios, you lose the decentralized validation and consensus brought about by a bunch of people incentivized to compete with one another to burn electricity.
To push this further, I was working on a research paper with Ron Rivest, Neha Narula (head of MIT's decentralized currency initiative), and Sunoo Park (a wonderful applied cryptographer) on whether blockchains in general could be helpful in casting and tallying.
But if everyone used a public blockchain, with proof of work + user-level signatures for each vote cast, wouldn't it be far more auditable than any current system? Ignoring implementation details, reaching a point where anyone could have a way to audit that their vote was counted (correctly) seems very useful. Using this sort of model, it theoretically wouldn't matter who completes the proof of work as long as the results are audited.
You don't need blockchain to enable voters to verify "that their vote has been counted correctly". Several cryptographic voting schemes already provide this feature (for example, Civitas and Floating Receipts).
My bet would be: marketing. Blockchain is hot, blockchain is sexy -- at least among people who aren't really technically inclined. (The technically inclined passed over the blockchain hype curve several years ago.)
There are tons of blockchain projects out there whose only real use for the blockchain is to be able to slap "now with blockchain!" on the sales materials.
> Trail of Bits engineers said Voatz' code was written intelligibly and free of many common security foibles, but added “it is clear that the Voatz codebase is the product of years of fast-paced development.” The summary goes on to list several technical flaws, such as a lack of test coverage and documentation, infrastructure provisioned manually without the aid of infrastructure-as-code tools, vestigial features that have yet to be deleted, and nonstandard cryptographic protocols.
That honestly sounds pretty good in terms of software quality, adding additional tests for proofs and ramping up ops are both addressable problems - especially if handled by a government sponsored team. But...
How confident are you that we could reach a well engineered and proofed electronic voting platform that also adheres to theoretical rules around vote security?
And which component of that, adherence to theoretical requirements and perfected development practices, do you see as a larger hurdle to overcome going forward?
> How confident are you that we could reach a well engineered and proofed electronic voting platform that also adheres to theoretical rules around vote security?
I don't think we can with the current commodity devices / ecosystem, even assuming that voting system software is well-written. Keeping electronic-only systems secure from nation-state level adversaries is hard.
I understand that current solutions to electronic voting are unsatisfactory, but I am fairly baffled by:
> It remains unclear if any electronic-only mobile or Internet voting system can practically overcome the stringent security requirements on election systems
Like, we can adequately secure banking software. With proper considerations and processes for the problem domain (i.e. user follow up / validation, alerts on suspicious vote changes) I don't see why securely implementing electronic voting is considered near-impossible, and has so few advocates.
To put this in short-hand: "We bank online, we buy all sorts of stuff online, why not vote?"
The biggest reason is that banking and other financial transactions have a very different threat model from voting.
In particular, voting requires a secret ballot. In addition to preventing an adversary from learning how you voted, a secret ballot requires you to be unable to prove how you voted, to prevent vote selling and coercion.
Hmm, I hadn't fully grokked the facet of the problem domain.
I guess you could give users a spoofing mode, that allowed them to fake any ballot / action. Or possibly, if there was a window of time in which they could change their ballot freely.
Maybe making such features both secure and accessible would be nearly impossible though.
Many bank transactions can be reversed, and the ones that can't can be covered by insurance or self-insurance. You can't practically speaking reverse a tainted election.
> Like, we can adequately secure banking software.
We really can't. Banking is riddled with fraud, and I say that as someone who works in banking and has designed online banking software. Even with continually ratcheting up security in banking software, use of MFA, encouraging customers to more-secure platforms (Android/iOS), fraud detection (various approaches on the back ends, edge, etc), fraud through online applications is many orders of magnitude higher than fraud in traditional voting systems.
It doesn't matter so much in banking because we can (and do) give customers their money back. We can't fix a broken election.
And that's before we get into the way online voting completely fucks election practises around vote buying, coercion, etc.
I wish people who think they understand computers and are clever would actually make the effort to learn something about either domain before saying stuff like this. It's very disappointing.
But we've developed processes that allow us to have a functional online banking system. Similar processes might be possible for voting - such as a confirmation and triage period like with ACH transactions, but a month long or something.
For vote buying, seems like all the software has to do is enable faking your vote to 3rd parties effectively. Hard, but seems doable.
Like, yes, it's a very hard problem. But we could stand to do more than scoff and write it off as impossible.
We can't secure banking, there are just a lot of undo processes, holds, and internal processes and cross-comms that make it so people don't lose all their money all at once and potential losses can generally be reversed, insured, bailed out, covered by someone else, or balanced out / hedged against. Even with that, fraud is rampant and heists worth billions do still occur digitally[1]. And these are financial systems that evolve constantly over centuries at this point. And the attackers still win sometimes.
The biggest thing the measures do is significantly decrease the known ROI on a target. For example, a credit card can be cancelled. Even if the bank doesn't notice and the person doesn't notice and you do get 100k off it, the fact attackers don't know that still reduces the value of the stolen credit card and therefore the incentive to steal them. Further the gain of 100k by an attacker may be split amongst cardholder, card issued, insurance, merchants, etc. so no one person actually loses 100k. These things all matter when building and securing new systems.
If you look at the cryptocurrency space in general, you can see what happens when you replace a credit card or swift with transactions that are similtaneously immutable, very valuable, and easily anonymous enough. The monetary value on anyone's Coinbase account, let alone all the Coinbase accounts, is so high that we've seen attacks[2] usually reserved for nation-state actors and by actual nation state actors[3], including sophisticated + targetted zero-days and bgp hijacks and all sorts of fun stuff. Not to mention the very high density of attacks that require lower effort and talent like sim swaps, phishing, spear-phishing, impersonation, typosquatting, on and on.
Regardless, if the potential gains to hack a bank are level 1, and crypto exchanges or private keys are a 10, then voting is 1,000,000.
The zero-sum nature of winning an election coupled with the potential gains from doing so are so large and so unfathomable that we have to assume that the lengths people will go to are unfathomably more than everything else we've ever tried to secure. Bc if you can gaurentee a win for a candidate or choose the candidate or change the candidate, you can do anything. You can own anything. You can control anything. You can make any amount of money. The limit is only your talents, abilities, moral compass, and appetite for risk.
To protect against a huge number of attackers, including nation state ones with essentially unlimited resources and the incentive to use those unlimited resources is…it's never been done. Again, back to Coinbase, they secure their crypto with...wait for it…paper. Generated and printed using randomly chosen, single-time, fully-airgapped machines. In a random location. In a Faraday cage.[4] That's how you secure billions when you don't have an undo button. With paper. While not even trusting the electricity flowing thru the cable.
As we saw in the 2016 election, Brexit, and lesser know elections across the globe, it takes very little to secure a win. With the right data (which is even more accessible today than it was in 2016) you only need to manipulate relatively small amount of voters. I'm too lazy to look it up but the numbers were insane when you looked at who was targeted by VoteLeave and Trump's campaign. They may have served 40m ads but it was only to like 40k people.
And that wasn't hacking anything. And those were huge-scale elections. And we still don't know who gained what from their outcomes, just that a lot of people spent a decent amount of money and a huge amount of effort to do so. And it wasn't selfless.
Small towns make gains more obvious. If small town mayor decides who gets the contract for building the new 10M town hall and if you can build it for 5M, you have 4.9M to spend on winning that contract. (Well 5M - resources to rig election - gain required for you to take the risk and put in the effort.) And, given the size of government contracts and their ongoing nature, the financial gains alone are massive. Military contractors: trillions and trillions.[5]
Even securing a single contract early on can ensure your success down the line. Maximus handles tons of Los Angeles welfare programs and now all sorts of programs around the globe. They have for 40+ years. They have billions in annual revenues from doing so. E.g. "In September 2012, the Illinois Department of Healthcare and Family Services awarded Maximus Health Services a two-year, $76.8 million contract to help the state with its Medicaid program. That same month, Maximus announced a $23.5 million contract with the State of Oklahoma."[6] Most of these contracts are decided not by the president but a random group of 5-7 officials at a meeting no one knows about where there is no competition and no real discussion.
Again, these are just a few very, very, very simple incentives people have to manipulate votes. Again, go look at 2016 Trump election or Brexit in depth to understand truly what is currently known about the number of people and the lengths they went to to get an election won. Without hacking. Check back in 40 years after more details emerge. We just don't even know yet.
The reason I have zero faith in any tech being successful in the nearish term with regards to voting is not that I think programmers suck or that politics is corrupt. It's that it's truly unprecedented on an incentives level and risk level. And, it's not just that the risk and potential loss for society or potential gain for attackers is so huge, it's also that we don't even know what it is, and even if we did, we wouldn't be able to comprehend it. How do you secure that when that's what you're up against?
The scope of what we do know about banking fraud, crypto fraud, and paper voting fraud is so great and we are always one step behind attacks and mitigate risk in millions of little ways because we can't fully reduce it. But you can't hedge against election fraud. There's no insurance. There's no undo button. There's no time travel.
And that means that, very unlike financial services, the amount you have to spend to secure an app of this nature is actually one resource more than the attackers are willing to spend to get their way in an election. Or one resource less than the amount lost if an attacker wins. But what even is the value of people, our future, our literal lives? Society, war, money, peace, contracts, the fed, interest rates, all the markets, all the debt, n95 masks, new buildings, old buildings, corruption, legitimacy? We can't know which of these attackers are going after therefore you have to protect against all. And there literally isn't enough resources in the world for that.
Zooming back down to simple: there isn't enough money to even secure an app for a single small town that has a single contract for $10M and will never have another contract and there is, impossibly, no other possible gain for rigging the election. I mean, there literally is enough money. But why spend $1M or $2M or $5M on that app? Why even spend a dollar? Why do so when it doesn't actually reduce all the other risks of election manipulation and corruption that are currently in practice while adding a whole new variety of known and unknown attack surfaces and exacerbates existing ones? You wouldn't. Period.
Why would a company try to build an app knowing this? Well, either they're optimistic and altruistic as fuck and don't know it. Or, second, they are taking advantage of you. Or, third and most terrifying, is the act of building a voting app itself is actually the way to rig the election.
Voatz, without a shadow of a doubt, is not the first. Perhaps the second. But the third? When you consider the timing of Voatz' fundraise, who they raised money from, the goddamn timing, the fact they didn't die when it was discovered they were using old ass php and plesk in 2018, and the fact the app is actually still this fucking completely worthless and insecure and hasn't improved, well, I can't say that it's not an attempt to rig an election but it's def not the US who's doing the rigging. They would go to far greater lengths.[7]
All of this doesn't undermine the fundamentals of the model I'm approaching the problem of online voting with. What is the potential upside, and is a system that reaps those benefits without compromising on security possible? I believe there are answers to most of these problems, providing you can restructure some aspects of voting.
It's not something I would advocate implementing in the nearish term, but I do think work can and should be done on it's fundamental problems.
One if the best/most frequent arguments against online voting is that there will be exploits and individual votes can and will be tampered with. So, lets take that in isolation for a second. Lets say I have to cast a vote a month in advance. I can change it for another month, but perhaps only in person. Is that enough fraud mitigation? What if that period is a year long? What if my political positions have been known by this app for years, and a dramatic shift in their distribution sends an alert prompting confirmation processes?
Essentially, is there some level of triage/verification process at which the online vote is considered acceptably secure? Well, if so, then can it be made compatible with a system that ensures ballot secrecy?
To flesh out my overall thinking of this problem domain – my kind of dream/ideal future of democracy is a system in which the positions of the electorate are "simply known". Right now we clumsily take a partial pulse every 2-4 years. But, if we had a system where voting (and polling) was "passive", then we could see the shift in sentiment way easier. Tampering would show in the data, or else have to be maintained for long periods of time. Essentially, the further we move from instantaneous votes, the better the process should get across the board.
To get a bit soap-boxy, if representation is a right as opposed to a privilege, then deepening and broadening it is an obligation of the state. More aggressively accessible in-person voting options would be good, but in the long run nothing will beat technologically-enabled democracy... if we can figure it out.
The biggest problem with Voatz is that it's selling silicon snake oil to people who can't evaluate claims.
It starts with the premise that somehow Blockchain does something magical. That is enables special security.
Claims like this are a load of crap.
What Bitcoin did, and what hucksters like Voatz are trying to cash in on, was to make it provably difficult to write a public record. In doing so, Bitcoin created provable digital scarcity (subject to certain well-known assumptions) for the first time in human history.
Voatz picks out the cryptographic part as if it were somehow separable from the proof of work part. The two are not separable. Voatz, and the fools who are using it, have much bigger problems than "improper use of cryptographic algorithms."
So I'm halfway through the report, it's a very beautiful document, great work from the team that wrote, and if I understood correctly, a VOTING application:
- Uses ad-hoc cryptography as the main cryptography
- Does not use the recommended security facilities on the target platforms (iOS and Android)
- Is deployed manually, with hardcoded secrets (AWS account with name "admin" had its credentials hardcoded in a scala file named "AmazonOtpUtility.scala")
- Has provably de-anonimizablity as a property (All is needed is apparently access to the databases, and might I remind you of the Twitter / UAE/Saudi Arabia recent story)
- (And this is the biggest, most annoying thing) Is not end-to-end verifiable.
- The actual threat model is almost childish, as showed by the testing team.
I do apologize for the wording in the following paragraphs, but this a fucking dumpster fire of a project for a voting platform.
Who the fuck authorized this to go forward as a voting platform for any state in the United States ? Who the fuck is selling this as a "secure" platform ? Can they sleep well at night ? When will the government intervene and stop people from compromising democracy with stunts like these ?
* Creds scattered throughout source code, including DB / AWS creds, "fixed" by removing but still present in git history
* Numerous crypto vulns: nonces / AES-ECB
* What's even the point of blockchain, it just makes everything worse
Selected quotes:
"Trail of Bits was only provided a backend for live testing on the second-to-last scheduled day of the assessment"
"The system is unusually complex, with an order-of-magnitude more custom code than similar mobile voting systems we have assessed."
"Voatz's voting processes are error prone and manual, relying on manual verification of voter identity and long-term storage of this identity on Voatz's premises"
"E2E-V systems allow voters to cast encrypted ballots such that ballot counts are verifiable to anyone, but individual voters’ preferences are not revealed. ... Voatz is not E2E-V."
"Storing voting data on a blockchain maintains an auditable record to prevent fraud, but this comes at the expense of both privacy and increased attack surface. Clients do not connect directly to the blockchain themselves, and are therefore unable to independently verify that their votes were properly recorded. Anyone with administrative access to the Voatz backend servers will have enough information to fully reconstruct the entire election, deanonymize votes, deny votes, alter votes, and invalidate audit trails."
I briefly commented on Voatz in my thesis[1] last year:
Voatz is another blockchain-related voting project. They claim to have been involved in a real world mobile voting experiment in West Virginia with real votes cast through their mobile application. However, their source code and voting protocol are not available for review.
Voatz is a great example of how commercial vendors can fill the letter of the law without filling the spirit: what they refer to as a ”paper audit trail” is literally a physical print of their digital records. If the digital records are corrupted before printing, the paper records will be likewise corrupted.
Based on the descriptions on the FAQ page, Voatz servers are all running the same software, and the voter needs their vote to be recorded on all of them in order to receive confirmation that their vote has been
recorded. This seems like the worst of both worlds: a single misbehaving authority can prevent the election from proceeding, and at the same time, the ”verifiable blockchain” benefits are undermined by running the same closed-source unverifiable software on all of the servers and the same closed-source unverifiable software on all of the clients. The replication of servers provides security benefits only against physical tampering of the machines – since the same software is running on all of them, an accidental or intentional flaw in the software can be exploited to manipulate votes on all servers simultaneously.
> The summary goes on to list several technical flaws, such as a lack of test coverage and documentation, infrastructure provisioned manually without the aid of infrastructure-as-code tools, vestigial features that have yet to be deleted, and nonstandard cryptographic protocols.
I’m not a security engineer, so what’s the benefit of using a nonstandard cryptographic protocol? That decision makes no sense to me.
"I’m not a security engineer, so what’s the benefit of using a nonstandard cryptographic protocol?"
Broadly speaking, the benefit is that if you have a keyhole view of the crypto world, you can google this and stackoverflow that online and get something that to your eyes appears simpler than using correct crypto, because correct crypto worries about keys, and revocation, and the keys are in a weird mix of formats, and certificates are complicated and have all these features you don't seem to need, and support for them is more mixed and less widely available than you'd like. Your simpler crypto seems to work, and it might be "faster", and it was easier to bash together one function that "uses" AES directly and puts out a stream that "looks encrypted" than it is to worry about all the things it takes to use crypto correctly.
None of that is sarcastic; especially if you don't stumble upon libnacl or some other library designed to be easy to use while still being correct, using crypto correctly is actually a good deal harder than misusing a couple of primitives to get something that superficially works. I mean, again no sarcasm, you can figure out how to bash something together with AES256 primitives faster than you can even figure out how to run a too-simple-for-your-needs Certificate Authority, which even if you do Google up the right scripts is still annoyingly difficult in my experience. And that's only a single element of what you may need to do for your app to be secure.
In terms of any other sort of advantage, there basically isn't one. It's the above advantage that is why we keep seeing home-grown crypto all the time.
Now, getting your use of the crypto primitives correct is much harder than getting your use of existing solid libraries correct. Unfortunately, misused crypto doesn't usually crash or segfault or fail visibly; it still produces binary gibberish visually indistinguishably from the binary gibberish solid libraries will produce. It just turns out to be low-quality gibberish that won't secure you or your users. But no segfaults, crashes, errors, warnings, etc.
The only reason to use nonstandard crypto is that you think you are smarter than the entire crypto industry. ProTip: you are never smarter than the entire crypto industry.
Fully agree. That's the primary issue associated with bringing a piece of critical civic infrastructure, such as voting, into the digital domain. Who builds, maintains and secures the tech? Certainly not the government. The govt only acts as a collective entity to support and promote strong tech-driven markets (it should at least in theory). I do hope that more individuals in the crypto industry get involved politically because of their technical wherewithal.
There's benefit when working in low-security environments. A custom crypto model will make your process harder to understand by a reverse engineer. This adds some security by obscurity, but almost certainly weakens actual security.
Let's say you just want to store and restore data on a user's computer, but want it to be difficult to read by an outside program. In this scenario, using an established algorithm makes it easier to decipher your encoding, and by nature if the encryption and decryption happens on the user's machine then you have to store the public and private keys on the user's system. There's no other way to accomplish this task if offline is a requirement. So in this case, obscurity has value in deterring reverse engineers.
IMO it's a security problem in practice - it means that you have a lot of organizational resistance to doing things like regular software updates, because you end up with this one server that's been hand-crafted that people are too scared to touch. Or, analogously, if you want to introduce some new sort of authentication/auditing/etc. protocol to the system, people will worry that they won't be able to find every use of the old thing and won't make the new thing mandatory. It also means that it's a lot harder to test changes, because you don't know what you need to set up to get a full test/QA environment going.
It's not a vulnerability in itself, but the fear/stop energy created by artisanal small-batch infrastructure is a good way to set yourself up for vulnerabilities being exploitable. (See, for instance, Equifax being hacked by a two-month-old Struts vulnerability - you can theoretically argue that Equifax is a big company and should carefully audit their dependencies, but a much more practical argument is that Equifax should have been ready to patch within days, at most, of the vulnerability being announced.)
The actual ToB report identifies another reason which I didn't think of:
> Ensure that all backend infrastructure is re-provisioned between elections and not shared between elections/clients. Each server should also receive its own unique SSL certificate and credentials. Use infrastructure-as-code tools like Ansible and Terraform to automate and manage provisioning.
Apparently there are two concrete problems:
1. All Voatz backend servers share a single wildcard certificate, and they think that automated provisioning would reduce the incentive to do things like this.
2. Every Voatz election uses a custom iOS/Android app delivered via TestFlight / Google Play Beta, because of some design choices in the protocol related to having a single shared backend (S3, MongoDB, etc.). They think that if there were infrastructure-as-code for the shared backends, it'd be easier to provision one instance per election and easier to make the client change to use a single client for each election, blocking potential attacks on the page that links you to the sideloaded app.
It also enhances auditability since you can keep a record of all changes in code and run the tooling to see if resources are changing outside of how they were configured. Without those tools, you'd have to develop your own to meaningful ensure infrastructure is setup correctly (it's not practical to hand inspect hundreds or thousands of small components)
> The clients do not interact with the blockchain directly, so there is no blockchain verification code in the client.
Fun. So, why even use a blockchain? Why not at least have light-clients with merkle verification? Does Fabric not have support for light clients (I haven't looked at it in a while)?
"Why even use a blockchain" is the first question that should be asked of any company that advertises they use one. Most of the time it's also the last question you'll need to ask...
Every time this company comes up, some part of me just shudders in horror at the thought of outsourcing the crucial act of voting to a company called Voatz.
Y'all the entire nation to put their trust in you and yet you have named yourself with a "cute" misspelling of one of the things you are involved in? Really?
I wish it could be safe, but real electronic voting fraud may be far more common in practice:
https://www.youtube.com/watch?v=zsNXnAv131g
Computer Programmer testifies that Tom Feeney (Speaker of the Houe of Florida at the time, currently US Representative representing MY district ) tried to pay him to rig election vote counts.
Usually they can be detected when exit polls differ from the voting results. But that seems common nowadays. So that is why I think that voting fraud may be common.
But back to the whistleblower.. How many have accepted the money? And how many of them are able do some underhand programming? Sometimes just to leave small security holes.
I don't think that MIT can detect them that easily. For a long time we did not even know the NSA encryption was compromised by NSA themselves.
Have my vote printed to a roll of paper, like a cashier's counter roll. Make sure that it shows through an opening in the case, so I can verify, and then rolls further (beyond the opening) so I cannot see it anymore. This is a way to store the votes "write only". The rolls are both human readable and machine readable (OCR is nothing new).
The only problem with this compared to voting forms is that form fall into the bin unordered, so it is harder to link a vote to a person.
Just an idea.
I would not trust ANY system that stores my vote on a re-writable storage medium. I know there are some crypto/blockchain tricks that may help, but that's so hard to audit for lay people that I prefer the paper roll any day.
Why even use a computer then? Paper ballots and hand counting work perfectly fine.
If for some reason you desperately have to use technology, optical scanners with statistical verification is probably not that terrible. One issue is that a significant part of the population won't be able to understand the verification part though.
Can someone confirm to me why we need voting "apps" or why voting needs to be electronic at all?
Vote in person by pen & paper or vote via mail remotely. Tabulation also should be done locally and in-person with representatives of all parties present.
Anything else seems ... like a way to more easily steal elections.
I live in Oregon where everything is vote-by-mail, and on the whole it works great. Each ballot is basically a generic survey-style scantron form and dead simple to fill out (fill in the circle next to your choice, or next to the blank line and write in a candidate), as of this year no postage is required so the only cost to the voter is a pen or pencil, and voters without a mailing address can register to pick up a ballot at the county elections office and can then drop off that ballot at any post office or in one of the drop boxes at libraries and public squares.
It also has overwhelming bipartisan support (>75% among both Democrats and Republicans) and results in turnout well above most of the country (63% in 2018 midterms compared to 49% for the US as a whole).
>>> "While the introduction of Internet voting in the U.S. is relatively new, the history surrounding electronic only voting is not. In the wake of counting errors, recount discrepancies, and uninterpretable ballots wreaking havoc during the 2000 U.S. Presidential race, Congress passed the Help America Vote Act (HAVA) [49], a bill targeted toward helping states move away from outdated and problematic punchard-based systems."
Well, consider how many people just aren't going to be bothered to ever register and vote which is the majority of my friends. The amount of effort plays directly into the "meh, not like my vote matters anyways" mindset.
"Oh well, they don't deserve to vote then" might sound good to you, but only if you tend to agree with what people currently vote for.
>> The promises of mobile voting are attractive—better accessibility for differently abled people, streamlined absentee voting, and speed and convenience for all voters. If a mobile platform could guarantee secure voting, it would revolutionize the process. It’s a fantastic goal—but there’s still work to do.
> If a mobile platform could guarantee secure voting
First, that's a mighty big if, and second, it's not enough!
Voting is a process where unlike online banking or online shopping there is no way for a human to go in and fix errors, there's no way to audit a vote and go "Oh, Bob meant to vote for A and Cindy meant to vote for B, so the machine did it wrong". It's not enough that an electronic voting system is correct, every single voter has to be able to trust the system, and for that it needs to be simple to understand.
You can't look at the electrons inside a silicon chip to determine they're doing the right thing. But with pen and paper and envelopes and urns and observers and counters, you can determine that the system is doing the right thing. Involving lots and lots of citizens in the voting system is not a bad thing, quite the opposite! You want as many eyes as possible on the entire process to ensure there's nothing shady going on, that there's no mistakes.
But if all the votes go into a black box that spits out the results, all of that goes away, all of that trust, all of that ability to verify that the results are correct.
Well, they use a lot of pen & paper in Russia, but somehow Putin can get 107% of votes in some areas. So perhaps your confidence in paper voting is a bit too high.
They never said you can't design a paper ballot system that can be corrupted... they just said that you CAN design one (fairly easily) that can't be corrupted and can be verified by most people (no special technical knowledge required)
Well, a completely uncorruptable, perfectly verifiable paper voting system does not currently exist and we haven't come even close to designing one. You're saying that we can design one fairly easily, so why is it that no-one has done so? If it's so easy to do, surely someone at some point would have done it.
Yes, if election workers are corrupt, your election results will be corrupted as well. No voting system can defend against it. That's what revolutions are for.
So you no longer stand by your original statement where you said "But with pen and paper and envelopes and urns and observers and counters, you can determine that the system is doing the right thing"?
Somehow you have gone from one extreme (implying that a traditional paper voting system is always trustworthy) to another extreme (saying that all voting systems can be corrupted), which, by the way, is not true either. For example, the results of a voting system where all votes are public, can not be manipulated. This tiny example shows that clearly some voting systems can defend against corruption.
> If a mobile platform could guarantee secure voting, it would revolutionize the process.
They'd have to give each voter some sort of voting device with a screen, buttons and wireless connectivity, and make sure that the voter doesn't lose it so that it can be reused for the next election, or buy these devices each election. Too much trouble.
Voting by mail shares many systemic issues with online voting, such as lack of anonymity (an attacker could open your letter or you could show the ballot to someone) and verifiability (you have no idea if your letter made it to the count).
Electronic voting is difficult because it's politically undesirable to many people who benefit from dead tree voting, not for any technical reason. So yeah, of course people claiming to solve a political problem with technical buzzwords are almost certainly selling snake oil.
I'm Mike Specter, lead author on the MIT report [1], and have been involved in other voting-related research projects [2,3].
LMK if you all have any questions!
1. https://internetpolicy.mit.edu/wp-content/uploads/2020/02/Se...
2. http://people.csail.mit.edu/rivest/pubs/PSNR20.pdf
3. https://www.belfercenter.org/sites/default/files/files/publi...