Back when we were putting together the grant proposal for ACCURATE, one of the questions that we asked ourselves, and which the NSF people asked us as well, was whether we would produce a “bright shiny object,” which is to say whether or not we would produce a functional voting machine that could ostensibly be put to use in a real election. Our decision at the time, and it was certainly the correct decision, is that we would focus on innovating in the technology under the covers of a voting system, and we might produce, at most “research prototypes”. The difference between a research prototype and a genuine, commercial system are typically quite substantial, in general, and it would be no different here with voting system prototypes.
At Rice we built a fairly substantial prototype that we call “VoteBox”; you can read more about it in a paper that will appear on Friday at Usenix Security. To grossly summarize, our prototype feels a lot like a normal DRE voting system, but uses some nice cryptographic machinery to ensure that you don’t have to trust that the code is correct. You can verify the correctness of a machine, on the fly, while the election is ongoing. Our prototype is missing a couple features that you’d want from a commercial system, like write-in voting, but it’s far enough along that it’s been used in several human-factors experiments (CHI’08, Everett’07).
This summer, our mission is to get this thing shipped as some sort of “open source” project. Now we have several goals in this:
- Allow other researchers to benefit from our infrastructure as a platform to do their own research.
- Inspire commercial voting system vendors to build better products (i.e., solving the hard design problems for them, to reduce their cost for adopting innovative techniques).
- Allow commercial voting system vendors to build on our source code, itself.
All well and good. Now the question is how we should actually license the thing. There are many, many different models under which we could proceed:
- Closed source + patents + licenses. This may or may not yield revenues for our university, and may or may not be attractive to vendors. It’s clearly unattractive to other researchers, and would limit uptake of our system in places where we might not even think to look, such as outside the U.S.
- Open source + a “not for commercial use” license. This makes it a little easier for other researchers to pick up and modify the software although ownership issues could get tricky.
- Open source with a “BSD”-style license. A BSD-style license effectively says “do whatever you want, just give us credit for our work and you’re on your own if it doesn’t work.” This sort of license tends to maximize the ease with which companies can adopt your work.
- Open source with a “GPL”-style license. The GPL has an interesting property for the voting system world: it makes any derivatives of the source code as open as the original code (unless a vendor reimplements it from scratch). This sort of openness is something we want to encourage in voting system vendors, but it might reduce vendor willingness to use the codebase.
- Open source with a “publication required” license. Joe Hall suggested this as another option. Like a BSD license, anybody can use it in a product, but the company would be compelled to publish the source code, like a book. Unlike GPL, they would not be required to give up copyright or allow any downstream use of their code.
I did a quick survey of several open source voting systems. Most are distributed under the GPL:
- Adder
- eVACS (old version is GPL; new version is proprietary)
- Helios (code not yet released; most likely GPL according to Ben Adida)
- OVC (GPL with extensions to require change histories be maintained)
- Pvote
Civitas is distributed under a non-commercial-use only license. VoteHere, at one point, opened its code for independent evaluation (but not reuse), but I can’t find it any more. It was probably a variant on the non-commercial-use only theme. Punchscan is distributed under a BSD-style license.
My question to the peanut gallery: what sort of license would you select for a bright, shiny new voting system project and why?
[Extra food for thought: The GPLv3 would have some interesting interactions with voting systems. For starters, there’s a question of who, exactly, a “user” might be. Is that the county clerk whose office bought it, or the person who ultimately votes on it? Also, you have section 3, which forbids any attempt to limit reverse-engineering or “circumvention” of the product. I suppose that means that garden-variety tampering with a voting machine would still violate various laws, but the vendor couldn’t sue you for it. Perhaps more interesting is section 6, which talks about how source code must be made available when you ship compiled software. A vendor could perhaps give the source code only to its “customers” without giving it to everybody (again, depending on who a “user” is). Of course, any such customer is free under the GPL to redistribute the code to anybody else. Voting vendors may be most scared away by section 11, which talks about compulsory patent licensing (depending, of course, on the particulars of their patent portfolios).]
I voted last week (Aug. 5th, 2008) in an important
primary runoff election here in the State of Georgia,
the State that, since 2002, has been the global poster
child for large scale, zero-evidence computerized
election fraud.
Unlike the vast, sorry majority of my fellow Georgians,
I have a high degree of certainty that the votes I cast
were counted because, being an informed voting rights
activist and computer professional who understands
the insanity of entrusting our votes to the manipulations
of programmers and invisible computer software, I made
certain that I voted on a PAPER Ballot. I’m certain my
votes were counted because I played the voting rules
of the State so that my ballot was not only PAPER, it
was PROVISIONAL — not only is there verifiable,
human readable, document evidence of my votes,
but the State is required by law to inform me if they
fail to process and tabulate my ballot.
Because my ballot of record exists in the form of
physical evidence, the processes of handling and
counting my votes CAN be openly monitored, CAN
be easily understood and CAN be totally transparent
to myself and all of my fellow citizens. The fact that
the “can be’s” AREN’T is a related issue of proper
chain of custody procedures, but the point here is
that, because they CAN be processed in full public
view, physical ballots provide the most simple and
direct path to legitimate elections. The tragic reality
for all the voters who don’t demand paper ballots is
that any real transparency or justifiable confidence
in the system is impossible regardless of other
voting procedures.
Unfortunately, in a nation obsessed with both technology
and convenience, we seem to want to convince ourselves
that increasingly complex technology will help us create
increasingly convenient voting systems. The big problem
is that the goals here are not convenience but accuracy
and accountability. We go out of our way to ignore the
obvious, common sense truth that the more complex the
technology, then the more obfuscated the processes, the
higher the costs, the more numerous the vulnerabilities
and the more likely the failures. My 25 cent ball point pen
and 3 cent paper ballot comes with a 100% guarantee
of winning any contest of voting system reliability,
accountability and transparency, even if one tries to
ignore their massive advantages in total cost of
ownership.
The Open Source status of the voting machine software
is completely irrelevant when the technology is being
so clearly misapplied. Any electronic voting system
that is not strictly relegated to producing physical,
permanent, human readable documentation as the
means of conveying the intent of the voter to the
tabulation processes will be incompetent in meeting
the most basic requirements of an election system.
The voting transaction is unique from most other forms
of exchange. The balloting process must provide total
transparency while also maintaining total privacy for
the voter’s choices. There can be no receipts issued,
nothing that connects any vote to the person who
cast it, in order to avoid vote buying and other voter
coercions that destroy election integrity. To achieve
this and maintain transparency, the ballot box and
the tabulation processes must remain open to public
scrutiny at all times. In this environment, Direct
Recording Electronic systems present a massive
and dangerous black hole in the chain of custody
between voter, ballot box and tabulation. Voters
should never be expected to entrust their ballot
decisions to invisible software manipulations of
any computerized vote collection or tabulating
system. Whether running Open Source Software
or not, and regardless of encryption schemes and
security protections, electronic systems employing
intangible balloting will invariably fail the essential
transparency test.
Note, however, that I am a Linux fan and not a
Luddite, so I’m not saying that the factual necessities
of election transparency should preclude employing
the practical advantages of computer technology
in the polling place. Though totally inappropriate for
storing and tabulating the actual votes, electronic
interfaces can effectively address many of the
challenges of voter accessibility and can help
reduce voter balloting errors when properly confined
to the roll of producing human readable, voter
verifiable ballot documents. This application of
computer technology meets the transparency
and verification requirements since, for every
voter and with every use, the system either
succeeds in producing an accurate ballot
document or it is removed from service. The use
of Open Source software in such systems would
be highly recommended in order to enhance their
transparency, but it is not essential when the voter
can clearly determine when the ballot printing
machines are malfunctioning..
The caution to remember for bringing computers into
the polling place is that any electronic election system
that is not limited to generating a voter verified physical
document of the voters intent as the ballot of record
do not just invite election fraud, the ARE election fraud.
The sources for electronic election results can never
be externally validated or audited under the open
scrutiny of the human beings who generated them.
Large scale election fraud and failure for voting
systems that rely on physical evidence requires a
proportionally large number of corrupt or incompetent
conspirators with an exponentially increasing
probability that their cheats or mistakes will be
discovered by public scrutiny. Election fraud and
failure on a Global scale becomes possible with
election systems that only store votes as invisible,
zero-evidence electronic chads. Massive fraud and
failures can be caused by a single corrupt or
incompetent programmer, and there is a very limited
probability of discovering cheats and errors because
there is nothing of substance for the public to scrutinize.
peace
Aaron Ruscetta
@supercat I agree. Probably the simplest way is to legislate the running instances’ disclosure. But if the powers that be are not making that happen, then some sort of legal jujitsu should be attempted through copyright law.
Of course, the best legislation is probably to ban electronic voting altogether.
And how will we obtain the “official source code†if the software is licensed under the GPL or BSD?
Election regulations should require its disclosure.
supercat says: “[…] by running the official source code […]”
And how will we obtain the “official source code” if the software is licensed under the GPL or BSD? The software isn’t propagated so it needn’t be made available by law. The copies running on the machines could be different than the versions initially publicized under a GPL or BSD scheme.
“I don’t think the AGPL would dissuade anyone intent on mischief.”
Of course. This is why all e-voting needs a paper count. But as far as a copyright mechanism goes to bring (at least in theory) the actual source to the voting public, the AGPL does it. Not the GPL, the BSD or the public domain. Again, this is software as a service so these licenses fail to do what is needed at the level of copyright law.
… the binary image being used precisely matches that produced by running the official source code through an open-source compiler…
supercat,
I’ll let Ken Thompson’s classic Reflections on Trusting Trust speak to this:
An open source compiler is not a sufficient condition. This classic result is general.
In this particular context, it points towards the necessity of detailed and domain-specific regulation of any machinery used for public elections.
I do understand that you’re arguing against the AGPL; I don’t mean to disagree with your result. But I think that all of us participating in what’s left of this discussion should to keep the fundamentals in mind.
If representatives of all interested parties are able to ensure that the binary image being used precisely matches that produced by running the official source code through an open-source compiler, the AGPL would be unnecessary. If representatives of all interested parties cannot check the binary image, I don’t think the AGPL would dissuade anyone intent on mischief.
Oops. Drop the ‘n’ from ‘nor’.
Yes, the AGPL.
We are dealing with electronic voting, not software on the users’ machines. Any choice of license that leaves the code vulnerable to discrepancy must be rejected. This is why the GPL nor any other typical free software license (or public domain) is the wrong choice. I expand on that here.
Of course, the code could be dual-licensed but the version used in actual elections that are supposedly democratic must be under a free network services-like license. In this case, I suggest the AGPL.
AGPL?
Seems obvious to me you need a something like the AGPL. The GPL wouldn’t work for e-voting machines because the software will be used as a service.
//For what it’s worth, I began this discussion with a bias in favor of the GPL. Now I’m leaning toward a BSD model, but I’m not yet convinced one way or the other.//
If a particular voting system were open-source, and some vendor decided to use that code as the basis for a closed-source system, would there be any reason people should trust the latter vendor’s equipment?
Ideally, anyone who’s interested should be able to request or download a copy of all the source files necessary to generate bit-for-bit the binary image that will go into a voting machine; that exact image should be verified against the code the machine is actually using. I see no reason why that ideal could not or should not be made reality.
If it were demonstrated that a completely-transparent open-source system was possible, then such a system could be required by regulations. Under such a scenario, the distinctions between GPL, LGPL, and BSD licenses would seem irrelevant.
//supercat, why are you recurrently hostile to me?//
Sorry, I was not intending any animosity toward you. The animosity in “completely useless” comment was actually directed at the people who have allowed some completely bogus election results to stand. It’s not your fault that there’s generally no procedure for regarding a tally as indeterminate, thus compelling officials to accept a reported tally, no matter how clearly bogus, in the absence of a specific more accurate tally. Even if one could prove that a voting machine was rigged to record votes for Dudley Do Right as votes for Snidely Whiplash and the 1,500 to 0 result should be regarded as highly suspect, there would be no remedy unless one could prove what the correct count should have been (*). Thus, after-the-fact detection cannot be regarded as a deterrent to election tampering. I’m rather peeved at the election rules and practices that create that situation, but any voting system must take it into account.
(*) If a candidate’s margin of victory in a precinct exceeds the number of voters, his tally may be safely adjusted accordingly, since there is no way such adjustment could make the result less accurate. Such adjustment, however, would still credit the “winner” with having received every single cast vote.
With regard to the sequencing issue, whether or not there is an official record of the sequence in which people vote, a running tally of how many people have voted would make it easy for someone to find out the serial number of a particular voter of interest (possibly himself). One requirement in a true anonymous system is that even a voter should not be able to prove how he voted except in situations of unanimity or near-unanimity (if all ballots but but one were marked for Dudley Do Right, and I know that I didn’t vote for him, I know that every other individual who cast a ballot voted for Dudley).
//On the other hand, subtle tampering with a cartridge could, in theory, make it read as blank to a DRE and not to a tabulator, depending on how similar the reader circuitry was between the two kinds of devices.//
There really wouldn’t be much to a cartridge. Basically a chip, some resistors, a cap, a zener, and a couple of card edges (a read-only port and a read-write port). If carts were assembled into transparent housings, producing a phony cartridge would be difficult (requiring access to custom silicon packaging facilities, at the very least).
Basically, as I see it, some requirements that I think are essential but which seldom seem to be addressed elsewhere are:
-1- Code must be executed exclusively from a read-only medium, whose contents must be verifiable, by all interested parties, via means not under the code’s control.
-2- The machine should have no persistent storage other than the cartridges, every bit of whose contents should be checked and accounted for before and after use.
-3- All interested parties should be allowed to read out the ballot results via read-only method (thinking about it, my particular proposal may not have been the best; if the machines had a serial port they could output their results while the ballot cards were still inserted). If all interested parties agree what the results were, that would ensure that any later alteration would be detectable.
-4- The design should be as transparent as possible, and any parts that are not transparent should be commodity items. Someone might tamper with a production line making XJ-5 ballot cartridges for purposes of tweaking elections, but one would be far less likely to tamper with a line making 29F256 chips, only a tiny fraction of which would be going into voting-machine cartridges. Many types of tamper-resistant designs interfere with transparency.
supercat, why are you recurrently hostile to me?
The sequence can be made nonsensitive by using a list-of-names-you-check-off rather than a blank-ledger-you-sign registration scheme, plus the observation that a person going to a polling place may wear e.g. a hood or a hat and not be easily recognized.
With respect to the blank-cartridge issue, the original suggestion was (implicitly) for the machine to reject a non-blank cartridge, not for it to merely report such. Reporting it is more sensible. On the other hand, subtle tampering with a cartridge could, in theory, make it read as blank to a DRE and not to a tabulator, depending on how similar the reader circuitry was between the two kinds of devices. If it’s not quite identical, a slightly below-spec voltage output on some line might read as a one bit to one device and as a zero bit to the other, for instance. Someone with the ability to replace a cartridge with a piece of electronics of their own devising that happens to outwardly resemble the real McCoy can obviously do this, and for that matter can make a cartridge that records nothing at all and always regurgitates zeros (swap these in at a precinct that predominantly votes Dem) or even regurgitates zeros until an internal, battery-powered timer runs out and then regurgitates a predetermined pattern of votes, etc.; it could even record votes and then itself contain circuitry to randomly flip a subset of the Dem votes or something.
Somewhere, the cartridges need to be validated. A cryptographic challenge-response authentication protocol could allow cartridges to prove their provenance; the ROM chip in the cartridge with the private key must resist nondestructive removal and transfer, and the cartridge must resist being nondestructively altered around that chip. Cartridges could also be tested by giving them test ballots and reading them back before wiping them before the actual election. A clock circuit with independent power could fool such tests by letting the cartridge behave until tabulation time and then “go bad”, but cartridges could be tested for being inert when not plugged into anything; a clock circuit will produce a small but discernible RF signal as it ticks. Carts could go by conveyor under a sensor head that could identify non-inert carts efficiently and quickly.
It sounds like there’s a clear conflict of interest in most state DA and AG offices.
This needs to be fixed, by having the DA/AG have the sole purpose of prosecution, and states hiring a different bunch of lawyers (even a private law firm) to defend them in litigation.
The people should also be legally recognized as having a cause of action if an election is tampered with.
Indeed, this thread has drifted. If people want to chime in on the original topic (how we should license this thing we built), I’d certainly appreciate that advice. For what it’s worth, I began this discussion with a bias in favor of the GPL. Now I’m leaning toward a BSD model, but I’m not yet convinced one way or the other.
Dan,
You started out with a fairly focused question: “What license should be used for voting system software?”
Early yesterday morning, after Jim March posted his initial comments, but before you replied to him, I thought about my reply to Jim’s charge that, “You guys are looking at this as a problem in computer science.”
My reply to him would’ve run along the lines: No, we’re looking at this as problem in public policy, partially informed by economics and engineering. The question of licensing for software deliverables from federally-funded research at a private university is partially a question of whether a pure public good should be converted into a toll good in order to promote both the federal objective to “advance learning”(note 1) and Rice’s objective to preserve, advance and disseminate human culture (note 2).
(Note 1: See English statute of 8 Anne and US Copyright Act (1790). Cf. US Const Art I, Sect 8, Cl 8.)
(Note 2: Human “culture” used in a technical sense: Culture is learned.)
But Dan, with your replies to Jim, this thread has drifted away from your original question about software licensing.
Jim March raises a curious conundrum. How can a voting system (any voting system) achieve transparency if the election officials running the show go out of their way to hide what they’re doing? The clear answer is that technology can’t solve this problem. You need to do something with the laws and regulations to force them to be transparent. In other words, VoteBox is a great way for an election official to prove to you that they’re doing their job properly. VoteBox won’t help if they’re clearly and uncaringly trying to hide what they’re doing.
The second issue Jim raises is the issue of poll rosters. Exactly how these things work varies from state to state. In my home precinct, if I vote on election day, voters’ names are printed in alphabetical order and you sign next to your name, thus the poll book doesn’t indicate anything about when you arrived. If I vote early, however, they print out a sticker with my name, place it in a book, and I sign it. That does indicate something about voter ordering. The devil is always in the details.
I’ll posit that vote integrity (versus tampering, ballot stuffing, ballot destruction, etc.) is a higher priority than voter anonymity (versus bribery and coercion). Obviously, we want to protect both integrity and anonymity, but if one of them is going to be weaker than the other, I’d rather err on the side of preserving integrity.
Quoting:
>>In some cases, most notably booth capture (when armed thugs rush in, take over a precinct, and cast as many votes as they can until the police arrive), VoteBox stores the encrypted votes in order, allowing you a shot at saying which votes were cast by the thugs and choosing to segregate them out prior to tallying. That’s much harder to do (but still not impossible) with paper ballot boxes.<<
PROBLEM: people sign the poll roster with their name in order of entry. So if you cross-reference the sequential list of ballots cast with the sequential poll roster, you can break voter privacy (determine who voted for what). This is easiest in a primary where voters are linked to a party as is their ballot; the voter registration data is public record and that links the voter to their party. Combining this data allows you to crack voter privacy…and if people think they can be punished for “voting wrong”, that leads to trouble plus it’s illegal as hell to even be able to do that…
Jim March
Please understand where my skepticism comes from. I experienced a worst-case scenario in the summer of 2005. While observing the election in San Diego County California, I was faced with a total lockout from the central tabulator facility. The county had set up the process within their sealed room so as to impede observation.
In protest and to establish our right to observe the counting of the vote, I walked into that room. That in turn led to 18 hours in the San Diego County jail under felony “election tampering” charges and a $10,000 bail.
(And some pretty bizarre conversations including one Mexican drug dealer sayin’ “hey, this dude WANTED to be in here!”…)
All charges were dropped a week later and fortunately I had the $10k available personally rather than via a bond that would have left me deprived of a grand :).
Still, the county’s willingness to jail me over this issue pretty graphically shows the level of opposition to transparency found in some counties.
Here’s the other scary part, and it has to do with the basic structure of government.
Let’s say you get the VoteBox approved along with dead clear rules for observation and use.
Great.
Now let’s say a given set of county election officials trample those rules into the dirt.
Who’s going to bring them under control?
* Citizen lawsuits? Sorry, the courts have ruled that we have no standing to complain about an unfair election. Literally, they say that a screwed-up election penalizes only candidates, who thus have standing to challenge.
* Candidate lawsuits? Yeah…see, most are gutless. Damned few are technically inclined. As case history one, look at John Kerry’s total fold-up within 24 hours of the 2004 election. He had scads of lawyers on tap and tons of ground to challenge on in Ohio and to a slightly lesser degree Florida, yet he closed it all down.
* The county DA? Ummm…several problems there. County government is often a very tight-knit club. Are you sure he’s going to rock the boat? In some states, there’s just one law office to cover both civil litigation (against the county) and criminal litigation. Arizona is like that. So the prosecutors are the lawyers for all county offices. You’re going to convince one to turn on their own clients criminally? Good luck.
* The state Attorney General? Same problem as the county DA above: he defends government entities against lawsuits. If he prosecutes one, he guarantees litigation against them…not in his client’s best interest, is it?
* The Feds? You need to study how the Bush administration severely politicized the Federal prosecutor’s system.
So basically, we’re back to “who’s going to guard the guardians”, the same questions the Romans faced.
Not only do you have to set up independent oversight, you have to have a legal mechanism in place whereby they can challenge violations of transparency and oversight.
To do that, you have to get legislators to pass a law that allows local gov’t officials to get sued for cash.
Do y’all have any idea what a lead balloon that concept is? In an age of budget shortfalls? And if the legislation doesn’t pass, great, you’ve put a tweakable system into the hands of people (county election officials) who you just tried to make legally/criminally liable. How do you think they’re going to treat your votes?
This isn’t theory, folks.
In the Sept. 2006 state primaries in Pima County AZ, three days before the election at 3:30pm somebody stole data. They printed out a precinct-by-precinct detailed “who’s winning” report (called a “summary report”). They printed another 15 minutes later, so it was hardly accidental. These revealed that state representative Ted Downing was in a nail-biter for state senate – and Downing was a serious reformer in the area of electronic voting.
He was running in the primary against another Democrat, with no Republican contender for the final (in other words, primary was it).
Within five hours of that data being stolen, a “robocall” went out to Downing’s district slamming him up one side and down the other with just pure horsecrap. It was set up to make it sound like it came from Democrats but at the very end was a quick “paidforbytheRepublicanparty”. Who supposedly had “no dog in the fight”. The call was paid for out of the state party HQ rather than Pima County, and the top Republican in Arizona is the Secretary of State – who manages elections, is a proponent of electronic voting, hated Ted Downing and ta da, was Bush’s AZ campaign chair in ’04. Ummmm…nothing suspicious THERE, right?
Did the data theft trigger the last-minute campaign activity, to knock out an active opponent of election reform? That’s sure as hell what it looks like.
This is not purely an engineering problem, OK?
Now let’s add one more quirk.
Pop quiz: who’s the biggest voting system software vendor in America?
A: Microsoft. Because Windows is buried in all the existing junk.
Question two: every time we do a reform bill that even hints at an open source solution, which 800lb gorilla worth of lobbying muscle comes in the state (or Federal) capitol to crash the party?
Do I even need to answer?
Microsoft views voting systems as one front in the war on open source. Get anywhere near that fight and you’ll get flattened so hard you’ll be picking tire tread out of your hide. Possibly literally – Balmer has a bit of a temper…
Still think this is an engineering exercise?
Sigh.
Jim March
http://blackboxvoting.org
supercat points out the importance of detecting tampering prior to the election rather than afterward. Cryptographic e2e mechanisms are generally all about detecting things in post-election audits. VoteBox brings this up to real-time, allowing evil machines to be detected while the election is ongoing, along with a “separation of privilege” style mechanism that would effectively require more than one machine in a precinct to be corrupt for the corruption to be able to do the equivalent of stuffing ballots.
What e2e cryptographic systems like this guarantee is that malfeasance will be caught (with increasing probability as the degree of tampering increases). What they don’t let you do is necessarily reconstruct what happened and when. To that extent, it’s very similar to traditional paper ballot box stuffing. You can absolutely detect that there are more ballots in the box than registered voters in the precinct. What you’re supposed to do then is ultimately up to the courts.
In some cases, most notably booth capture (when armed thugs rush in, take over a precinct, and cast as many votes as they can until the police arrive), VoteBox stores the encrypted votes in order, allowing you a shot at saying which votes were cast by the thugs and choosing to segregate them out prior to tallying. That’s much harder to do (but still not impossible) with paper ballot boxes.
You’ll have proof that the totals they’re publishing have nothing to do with the raw votes. Proof you can take to a court and use to demand redress.
Absolutely useless. What is going to happen if, in an area that’s about 75% Evil Party , it’s discovered that a voting machine was tampered with, and it happens to report 20,000 votes for Snidely Whiplash and 439 for Dudley Do-Right? Despite the fact that there were only 20,147 voters? Obviously someone tampered with the machine to add 288 votes for Dudley Do-Right.
Machine tampering must be detectable before the fact. Being able to conduct forensics afterward may be helpful if it’s necessary to bring criminal charges against anyone, but will be useless for purposes of ensuring fairness in the current election.
This is partly a reponse to Jim March, but more largely, an attempt to explain how end-to-end cryptographic systems can and cannot address some of the concerns that he raises. There are a number of different e2e mechanisms, so I’ll stick with the ones that VoteBox uses for concreteness.
First, an overall perspective. VoteBox is designed such that you never have to care whether the election officials have a virus-ridden poorly-administered tabulation system. Well, you’d like for them to do better, but now you can independently verify whether their totals make sense, and you’ll have proof of when they don’t. You’ll have proof that the totals they’re publishing have nothing to do with the raw votes. Proof you can take to a court and use to demand redress.
The VoteBox design has every polling place connected one-way to the Internet (data gets out but doesn’t get back in). All of the encrypted votes go to our favorite election officials who then broadcast them to anybody who cares (think of the encrypted votes as being available as an RSS feed or something). You can the subscribe to that feed with your own computers, running your own software. You can also “add” the votes together yourself and reach your own (encrypted) tally. You cannot decrypt it to get the final answer, however. That requires a coalition of election officials, party officials, and whoever else. (Let’s call them the “trustees”.) They each take the encrypted election totals and do their share of the decryption. These shares are then combined, and out pops the election totals. (If one of the trustees were suspicious of the election officials, they could do the very same tallying operation that you can do, and then submit their share of the decryption.)
The trustee sharing mechanism guarantees that nobody can decrypt any subtotals of the election. No evil election official can check in on how any particular voter cast their vote. However, anybody can verify that the official decrypted totals correspond to the encrypted totals that they can compute themselves.
Of course, using the Internet is a bit of a gamble. What if evil attackers knock the election officials’ machine offline or otherwise interfere with the process? No problem. All the VoteBox machines retain copies of everything that happened in the polls. You can physically bring them back home and do everything without the Internet. (The Internet is for convenience and speed, not for correctness.)
We’re not done yet, though. We need to make sure of three things:
1) The votes that are being broadcast out are the same as the votes that went in. (In other words, we need to make sure that nobody changed any of the encrypted votes coming out of the precincts.)
2) No additional votes were added in that didn’t come from the precincts (i.e., no ballot stuffing).
3) The encrypted votes correspond to the intent of the voters (i.e., no evil machines flipping voters’ votes).
#1 can be addressed in a variety of ways. For starters, any voter is welcome to take home a printed copy of their encrypted vote. They can’t decrypt it, but they can verify that the official election feed includes their vote. You could imagine a party organization or the League of Women Voters doing this sort of verification en large.
#2 is a bit trickier. VoteBox has some clever mechanisms that prevent a single corrupt voting machine from being able to generate votes without detection, but if the entire precinct is corrupt, VoteBox can’t help here. Instead, you still have to look at things like the total number of voters signed into the precinct. If you see millions of votes where there should be a hundred, at least you can see that as plainly bogus and you can argue before a judge that these specific million votes should be dropped while the other precincts are still good to go. (You’d do exactly the same thing if you found a paper ballot box that was overstuffed.)
#3 leverages a clever challenge mechanism invented by Josh Benaloh that we’re using. Roughly speaking, voters start off with a “normal” DRE experience, all the way through the summary screen. After that, there’s one new screen saying “cast or challenge?” At that point, the machine has already sent out your encrypted ballot, digitally signed, but the machine has no idea if you’re going to challenge or cast the ballot. If you cast it, another message is sent out saying you’re done. If you challenge it, the machine broadcasts a key that lets anybody decrypt and verify the vote (and will alert anybody tallying the vote to skip that particular challenge ballot). If the machine was flipping votes, you would now have it caught, red-handed, cheating on the election.
The cool aspect of #3 is that you could imagine organizations like the League of Women Voters developing an auditing wing. Auditors could arrive at the polls, while the election was ongoing, and declare their intent to challenge a particular voting machine. Bring in your video cameras. Have a ball. All the people know what you’re doing, but the machine has no idea. (As a safeguard, you might have the final “cast ballot” button be something that can be locked under a clear plastic door to prevent auditors from accidentally casting a test ballot.)
(If a voter challenges their vote, then the challenged vote will not be counted in the final election tally. The voter should then be offered the chance to vote again. The supervisor console, in the voter’s precinct, will warn the poll workers that they’re supposed to do this. If you’ve got evil poll workers, they could ostensibly try to confuse voters on this point.)
March then asks whether anybody will be allowed to actually do any of this. That’s a good question. The security of a VoteBox election depends on people doing this auditing. That can and should include regular voters as well. This is where academia ends and the real world begins. VoteBox, and other e2e systems, have very nice properties that mean you never again need to storm into the election headquarters and demand to see what’s installed on their PCs. However, for the system to be trustworthy, there need to be independent actors performing audits during the election day. Likewise, the VoteBox design depends, in a real way, on everyday voters and poll workers being able to understand how a VoteBox election feels different from a standard election. A VoteBox election would have very different regulations and procedures than a standard election. In some states, that would require big changes in how the laws regulate what can go on in a polling place. If election officials using VoteBox were to somehow forbid anybody from performing the challenge procedure, that would defeat the whole purpose of using VoteBox.
Our job as computer scientists is to show how to build a better voting system, and we’re making good progress. Ultimately deploying such a system, just like deploying any other voting technology, including hand-counted paper ballots, is going to require getting lots of little details right.
You guys are looking at this as a problem in computer science.
That’s only a SMALL portion of the problem.
I was an official election observer in Monterey County California during their most recent election (just a couple of months ago).
Under California Election Code 15004 I’m allowed to do a pre-election tech inspection of the machines. A really minimalistic reading of that statute says that I can make sure the systems are of the certified, official type and running in a certified, allowable state…which in turn means no Internet connection, no connection to the general county LAN, no added uncertified software.
The moment I suggested they pull up the Windows “add/remove software” screen so I could see what was loaded, they balked and said they’d have to consult with their attorney. Ohhkay. After an hour and a half’s wait for said county shark, I was able to determine that they had literally snuck back into the central tabulator room through the warehouse and were in there messing around with, you guessed it, “add/remove software”. I photographed the screen and was threatened with arrest. After a two-hour wait for deputies, said deputies (or maybe their bosses) realized they’d face a major suit and they all backed down. When we finally resumed we found MS-Access loaded on the two machines they hadn’t sterilized yet when I caught them earlier.
This was a Sequoia shop. Ballot data is prepared via a program called “Ballot Preparation Software” (BPS) in MS-Access format. MS-Access could be used to hand-alter the data before it’s pumped into the central tabulator system.
What does all this mean?
It means techno-solutions are useless until we establish, by law, genuine independent oversight, PLUS that oversight has to be simple enough to carry out without a CS degree in advanced geekery.
Put another way: you say there’s ways to “cryptographically verify” the election while it’s running? Cool. MY question in return is: will anybody be allowed to do so?!
Until there’s an answer to that, we’re not going to get visibly honest elections.
Jim March
Member of the Board of Directors,
http://blackboxvoting.org
Well, there is one. If the running system never has access to any personally-identifiable, potentially-anonymity-breaking data then it can’t sneakily record it anywhere.
How can a voting system not have access to the sequence in which ballots were cast? Since the sequence in which people arrive at the polls is recorded and could not very well be kept secret in any case, knowledge of the ballot sequence would destroy anonymity.
This, or the more aggressive “on power-up, the software should wipe the ballot mediaâ€, has a problem if there’s a power failure during the election.
I didn’t specify that the system should lock up if the ballot cartridge is not blank, but it should give an indication of that fact. Using external reader equipment to check that ballots are blank would be more labor-intensive and offer more opportunities for sleight of hand. Having the machine power up with an indication of either “BALLOT CARTRIDGE BLANK” or “CARTRIDGE NOT BLANK” would be more convenient and offer less opportunity for tampering.
You ask “how we should actually license the thing.” You seem to assume you have to license But you don’t. The alternative to licensing it is to release it into the public domain, relinquishing all copyright rights.
I’m not arguing for or against that alternative. But it seems a blind spot that you aren’t even considering it.
As yet, they’ve shown no inclinations toward even trying to “engineer the best system that they can”; why would you expect that to change anytime soon? 😛
Well, there is one. If the running system never has access to any personally-identifiable, potentially-anonymity-breaking data then it can’t sneakily record it anywhere.
This, or the more aggressive “on power-up, the software should wipe the ballot media”, has a problem if there’s a power failure during the election.
Better would be for the media to be verified blank just prior to insertion in the machines. Best would be for this to be done by write-protecting them, plugging them into the same tabulation system that will be used later for the actual tally, and verifying that the tabulation output is all zeros; if not, testing each piece of media (in parallel!) to identify which one(s) are compromised and replacing these, repeating as needed. When a set of media gets confirmed clean, they’re all de-write-protected and plugged into the machines, and the machine seals applied, whereupon the polling station is about ready to open its doors.
Dan –
The questions you ask at the end of your piece indicate that you have some serious misunderstandings about the GPL.
1) As has already been pointed out – by distributing your code under the GPL, you do *not* lose your copyright.
2) The notion of who is bound by the GPL’s terms is quite clearly defined in the GPL, and manifestly does not include someone who would merely be voting on a machine running GPL software.
3) In fact, the GPL makes no requirements on “users” who compile a GPL program or run it on their machines. In fact, you can even make changes to the code and run them on your machine, so long as it stays within your company.
4) The only time you are affected by the GPL is when you want to *redistribute* the changed code, which you would be doing if you went into business making machines that ran modified GPL code, say in an EPROM. (This situation has arisen when router manufacturers used GPL code.)
If I made a single voting machine using modified GPL code (say as a kiosk) and put it in a store, if it was my store and my machine, I am reasonably confident that I wouldn’t be construed as “distributing” the binaries to anyone, and would have no obligation to distribute the code to the people who vote on the kiosk.
The one gray area I see is a case where Diebold (say) made some machines and *leased* them to customers who treat them as a black box. I don’t know if they would be held to have “distributed” the modified GPL code.
A non-proprietary voting system protects the voters’ right to vote. It allows for public scrutiny of the voting process. If your system does that, licensing is a moot issue. You might want to visit the Australian experience, and/or download their election software. Their research indicated the only way they could protect their voters’ right to vote, was to use open-source software. They have had that software freely available for download on the Internet for several years. It can be downloaded, modified, and used without restriction. But then, the U.S. knew that a decade or more ago.
If this works as advertised (and I’m a huge skeptic at this stage) then publication of the methodology (thus making it impossible to patent) is vastly more valuable than ownership of any code copyrights. Knocking up a fresh implementation can be done relatively quickly if enough people are convinced that the voting system is worthwhile. Indeed, multiple independent implementations would be a requirement to making it trustworthy. Don’t worry too much about your license, or even just don’t publish any code at all, only publish the methodology and see how long it takes before someone pops out a GPL version.
You have not fully explained your goals with this project. If you are building this code to promote your own good name, and in the hope of improving the world you live in, pass a legacy on to the children (who will one day take your place) and maybe actually improve our system of Democracy then the modified BSD license is the best choice (i.e. the GPL-compatible BSD license).
If you want to make money then I suggest that you use the GPL, with a note saying that vendors of proprietary equipment should contact you about alternative licensing options (be careful about keeping your code pure and not merging in bits of other stuff you find around, so you have the ability to dual license).
If you want to concentrate on actual research (i.e. discover something new) then best to use nothing but GPL (because that’s what the other similar projects are using) and you should grab as much headstart from their work as possible to avoid reinventing the wheel (unless you genuinely believe that you have a unique and better approach to make a clean start worthwhile).
As a quick side note, GPL does not require publication, distributers only need to deliver source code to the customers they deliver binaries to. In the case of voting systems, this may only be a small and (shall we say) impressionable group of people.
Also, ALL versions of the GPL require change history to be recorded, at least as much as:
An extended version may require more detailed change history… BUT be careful with “extended” versions of the GPL because the FSF owns the Copyright of the GPL itself, and does not offer permission to modify that license (also because “extended” versions might be incompatible with every other piece of GPL code out there). In practice, I’ve yet to ever see this enforced, especially w.r.t. small details of administrative procedure such as change histories.
Please apply all normal legal disclaimers here.
However, they would also be at an advantage in already having pre-tested code subject to extensive public scrutiny and possibly be in a position to push for regulations to force source publication and public scrutiny onto their proprietary competitors (who will have more difficulty adjusting). Software development can be very expensive (especially in a closed shop environment), so the proprietary competitors are up against considerable money burn which the Open Source business can spend on better hardware, better integration, and polishing all those small details that are part of the final package but not actually part of the core GPL application. They don’t have to release their GPL source until they actually deliver a product, so there will be a time lag before the competitors get hold of that and produce a working deliverable.
What’s wrong with the LGPL – you get the advantages of the GPL, with the publication requirement and the guarantee that the code will stay open source, but its also fairly business friendly because they can link to it like normal code, and don’t taint any propitiatory / patented stuff they want to add in.
I certainly didn’t suggest the “publication required” license because 1) it’s a strategy that I’ve never heard of and 2) it fundamentally misunderstands software licensing via copyright. I have a blog post I’m working on that I’ll finish tomorrow that will serve as a larger comment on this post, Dan.
Just FYI, NSF is starting to put “appropriate open source license” language in most of the software funding RFPs I see come out of OCI/CISE. So your grant may not require it, but your future ones probably will.
There is no way, short of being able to completely examine the system’s code and the hardware that it is running on, that one can ensure that the voting software preserves any sort of anonymity. The problem is fundamentally unsolvable because there is no way to prevent the software from doing what it’s supposed to and also either keeping a covert log or inserting a covert data stream into supposedly-random data.
Another issue to consider is that it is not really sufficient to allow fraud to be detected after the fact. Governor Gregoire of Washington was awarded a “win” on the third recount despite the fact that in many precincts the number of ballots exceeded the number of voters, and the number of excess ballots exceeded her “margin of victory”. If someone loaded a machine with bogus software that awarded 51% of votes to the Lampshade Party candidate, it may be possible to prove after the election that the machine was rigged, but by then it would be too late.
IMHO, a good voting machine should have the following characteristics:
-1- Machine software and parameters would be stored on physically-write-protectable media (e.g. cartridges) which could be read out with a fairly simple reader. Before the election, the media should be write-protected, and the write-protect control physically sealed; each interested party should supply a representative with a reader which would be used to confirm the contents of the media.
-2- Ballots would be stored on similar but separate media. That media would be writable during the election and write-protected afterward.
-3- Both types of media should be sealed inside the machine during the election; on power-up, the software should confirm that the ballot media are blank.
-4- After the election, members of all interested parties would supervise the unsealing of the machine, the write-protection of the ballot cartridge, and the sealing thereof. Then all interested parties would read out the ballot cartridge and exchange digitally-signed copies with each other. All parties could thus confirm that they had read out the same data. All parties would also reread the software/parameter cartridges to confirm that they were unaltered.
-5- The machines should have no persistent memory of any sort, other than the cartridges.
-6- Full design specifications of the machine would be readily available to all interested persons.
Such a system should not be hard to design. I don’t really see much benefit to incorporating cryptography; if the hardware, code, and physical media handling are trusted, cryptography is not necessary; if those things are not trusted, cryptography is insufficient.
I think it should be required that voters can see the source code. That is important because otherwise, there’s the risk that a company can say “Our code is safe because it’s based on this code written by the academic experts!” even if their code does not in any meaningful way contain the security guarantees of the original. For instance, I could imagine a system that happens to import some command-line parsing routines but doesn’t actually contain any of the crypto stuff, and is still marketed as “based on” the system that had the real crypto stuff. *Requiring* credit a la BSD licenses only makes that issue worse. Security is easy to destroy, by accident or on purpose, and visible source code is necessary (though not sufficient) to ensure that it is retained. Companies shouldn’t be allowed to say they used the code unless it can be verified that they really used it properly, and I think that means verification by examining source code, even if the crypto stuff is designed to make examination of source code unnecessary.
However, it’d be nice if corporations could use and profit from the code as much as possible to the extent their doing so is compatible with that requirement, because that may encourage adoption.
A couple clarifications:
The voting system is already done and imminently ready to ship as soon as we get the web site and all the ancillary stuff complete.
The work was funded by the National Science Foundation (that is, by the American taxpayer). Neither the NSF nor Rice University have any particular policy with regard to what sort of license should be applied to funded research. (Historically, Rice tried to own everything and charge licensing fees and so forth. That’s a battle that I’m thankfully not going to have to fight.)
As a practical matter, any license is going to need to have some variant of a “no warranty expressed or implied; no fitness for any particular purpose; no guarantee you can use this without violating somebody’s patents; no way you can sue us if you don’t like it; etc.” clause. I think we have some three paragraphs of canned all-caps verbiage to that effect.
Beyond that, I’m looking for productive suggestions on what sort of terms we might use. Thanks.
> Open source + a “not for commercial use†license.
That is impossible, by the definition of “open source”. Please use the term correctly. See opensource.org for the definition.
Quick question. How would the voting system software be produced? Would it be produced by your own time and effort OR would it be funded by through a government grant.
If done through your own efforts then you could implement whatever licensing scheme you choose. Hopefully open source.
However, I hope that I am not lost in the wilderness on this, if the development of the software is funded through a government grant the software should immediately fall into the public domain when released. So no license at all.
If you’re willing to go BSD, just go public domain. The only difference is that the BSD license puts a legal obligation on users of your source code to include attribution in various places, which is “nice” but is it really worth encumbering them with that obligation? Actual programmers have to do actual work to make sure the notifications get to the right places so they’re not in violation.
I’ve heard from multiple acquaintances of mine that they were able to make use of public-domain code I’ve released on projects where their lawyers were too paranoid to allow even BSD licensed code. It’s certainly possible that something GPL-ish or something publication-required might lead to more use and more net societal benefit overall — it’s possible that enforced sharing leads to more stuff — but it’s highly unlikely BSD leads to more net societal benefit than public domain.
You should publish it using a BSD-style license. The decision to require voting machines to release their source code needs to be separately enforced by law. Using a GPL license will make this law less likely to happen, and vendors will use workarounds to avoid publishing.
Let’s assume for the moment that at least some of the current vendor base will try in the short run (next few election cycles) to stick to the old model of closed source, NDAs and trade secrets. If the license is GPL, then any new or existing vendor who uses it will be in the position of spending all the time and money to get the initial certifications and contract wins, and then handing their code over to the vendors who have stayed with the closed-source model and relied on, uh, close ties with the customer community to make their sales. If I were a current or potential voting-machine producer, that wouldn’t necessarily look like a good deal to me.
It seems that you want two licensing regimes: one for research and noncommercial use that would emphasize easy adoption and wide publication, and another for commercial application that encourages/requires open publication of derivative code while not clobbering all chances of commercial advantage. Is there any kind of license that would bind commercial users to publication with RAND licensing terms for their versions?
…. I’d recommend BSD plus publication required….
I’d (mildly) recommend against creating a new license. Open source license proliferation can be discussed elsewhere, I’m mainly objecting to the level of legal and community effort required to write and vet a new license today.
Dan brings up a good point about differences between voting software and other types of software. But, the nature of good research is to stray out of the narrow confines that the investigators envisioned. Someone down the road who wants to use the software may not be building a voting system for public elections. They may actually be doing something, like –I dunno– maybe climate modeling.
I think keeping the source for software used in public elections open to public inspection is better accomplished through direct regulation of the software that may be certified for use in a public election.
Let me start by assuming that your goal is to maximize the security and verifiability of actual elections. In this case, I’d recommend BSD plus publication required. My reasoning is as follows:
1. You want voting machine companies to use it. Hence, impose few restrictions. This argues toward BSD.
2. You’d like to have independent experts verifying the security of real systems in the field. Hence some sort of publication.
3. Vendors would probably like to be able to innovate in software, without giving their competitors the right to copy their code directly. Hence not GPL. (Competitors would still be able to read the code become informed by it, and build their own, but not copy. This might save competitors a little time and money, but not much.)
Let me stir in one point that makes this system somewhat different from “normal” software. Due to the cryptographic machinery in the voting machine, it’s possible to verify that the machines are operating correctly without actually needing to read the source code. That means that it’s not strictly necessary, from the perspective of election security, for the code to be GPL. On the other hand, we’ve been saying all along that trade secrets really don’t have a place in elections. GPL can coerce a vendor to abandon trade secrecy while BSD allows it.
Kiaser said: “the code and any changes will available, and if its not available you have an established legal remedy”
Maybe. Companies are also not bad at finding ways to incorporate GPL code without ‘infecting’ the rest of their systems, eg. by breaking things into separate processes and communicating via some channel that doesn’t constitute linking. Then, you’re not getting much code back and you’ve forced them to make what may be a less than ideal design choice (depending on the details of course) for no gain. If you go BSD/MIT/ISC, you’re at least giving them the freedom to engineer the best system that they can.
Time frame makes a bit of a difference.
Short-term, BSD is most corporate friendly. When Microsoft jumped on the TCP/IP bandwagon, they did so with BSD licensed code. If you want the code to be used to count actual votes, BSD is the way to go. The problem is that you probably will not get anything more than an acknowledgment that *some* of the code has been used, so you have no idea what parts are in use or how broken they have become.
Long-term, GPL will make the right things happen. Existing vendors may not exactly jump at the chance to use the code, but when someone does decide to use the code, the code and any changes will available, and if its not available you have an established legal remedy. After watching GPL licensed projects for many years, it has become apparent that the GPL will protect the code.
kz
GPLv3 is the most ethical (natural rights respecting) license currently available.
Perhaps also transfer the copyright to http://www.usccr.gov (such that it is never abused, e.g. upon termination).
Dan,
Was this research supported by federal funds?
(Haven’t had time to read the paper yet, sorry if I’m missing a nice grant number acknowledgment in there).
If the project or any portion of it was significantly supported by federal funds, then I believe a new BSD-style (3 clause) license is most appropriate for the part the taxpayers funded.
I understand that federal policy has leaned in the other direction lately: That is, it’s leaned towards giving universities greater control over their federally-funded research. I understand the reasoning behind that recent policy. I just disagree with it. I think the recent federal policy is counter-productive and unfair.
Dan,
First, you compare a “publication” license to the GPL by implying that the GPL requires a relinquishment of copyright, but of course you know that the GPL is in fact built directly upon copyright; releasing code under the GPL does not relinquish your ownership rights as an author.
Second, there’s nothing that prevents you from releasing the code under multiple licenses; see Qt and MySQL and various other commercial enterprises for examples. If a vendor wanted a closed license to the code they could purchase it from Rice, or they could go with the GPL released code and follow its requirements.
Finally, releasing the code under the GPL actually might be appealing to hardware vendors. It would allow them to compete on hardware differentiators (ease of use, security, print systems, support) etc. while levelling the competitive playing field from the software/functionality point of view. It could also potentially allow them to more easily be “certified” by states if they’re using open code which has passed some suite (see OpenSSL and FIPS for an example).
One other Rice project which is releasing their code under an open source license (you may know of others of course) is Connexions: http://cnx.org. You might consult with them on their copyright issues, discussions, selections, and sustainability model(s) for not only code but content.