Copyright (C) 2003, 2004, 2005, 2006 Jos Boersema Design (quick): --------------- Gives each voter a random code for each vote, sends the voter a ballot, processes returns into hard-to-secretly- manipulate result lists which are to be published back to the voters. Sede is a program for vote administrators. Design (user view): ------------------- Walk through. a) Voters are to be registered in a file by a method of your choosing. How this is exactly done falls outside of the scope of the program. The reason for this is that there are too many ways in which someone can decide who the voters are. b) The program creates "ballots" for voters (text files), each with a unique "code" in it for each polling on the ballot. The content of the ballot and its format is user-defined, it can contain an unlimited number of polls. c) The program sends out these ballots to the registered voters, or you send the ballots out with your own commands. You can encrypt ballots using command-line tools that create encrypted files, through the same interface you can also zip them, etc. d) The voters send the ballots back filled out (if they chose to). e) The program processes the returns with one command into several result lists. When duplicate votes are received, or when invalid codes are received, not registered for any voter, these votes are scrubbed from the list of votes, and placed on "garbage" lists for voters to also see. The length of the vote code is user-defined, and defines the strength of the poll against brute-force attacks. This strength is 63^N where N is the vote code length, so the strength mounts dramatically for longer codes. A vote code of 60 characters has a strength of: 912920516330797989897501319100671163424552283060748314636667478807055\ 142893152629668193590354000850926342401 possible codes, which is for instance a considerable amount of emails to spoof. Spoofing doesn't even guarantee manipulation, because the actual voter's vote could become the chosen vote by accident, or the vote-administration can decide to throw out or put at lowest precedence suspicious ballots; and then the critical voter-check of the results can 1. make known any manipulation and 2. correct this manipulation using an alternate communication channel (for instance paper mail, which is an anonymous channel). g) The votes are also tallied (for the ease of the voters), but this is NOT an essential step: publishing the votes with their vote-codes is the essential step. h) The list of votes is displayed on the "results page" to the voters. Here each voter can identify his votes, and see if they are registered correctly, and counted. The voter can also read comments of other voters. If a vote is registered incorrectly, the voter can ask a change by contacting the vote administration with a password, negotiated during the voter registration phase. This contact should take place over an alternative channel because the ballot-channel could have been compromised. Paper mail would do if the default channel was email. *) Some of the best features are: User defined voting area, no fixed magical content required. Free format voting, or pre-formatted voting. Comments for each voter per vote. Question randomization on the ballot (option locations). Each ballot can be different, depending upon registration information, containing different information and/or different questions, or even be send at all. Unlimited voter registrations. Unlimited number of questions per ballot. Weighted voting. Very powerful ballot generation process, though if not needed the ballots can be extremely simple, including real-time debugging. User friendly poll configuration command. A satisfactory setup can be used and reused forever on different polls, bringing the overhead on ballot creation/setup down to a minimum. Design (conceptional view): --------------------------- The technique outlined below is basically the same as the program uses, but is not tied to computers. Let your voters into a room. This is your voter registration process. - With the program you would "let them into your voter registration file". Take a deck of cards (because of the limitations of this resource, you can only take on 26 voters with this deck), and split it into black and red cards if you have two options to present to the voters. - With the program this is like asking the voters a yes/no question. Give each voter a red card and a black card, from these two stacks, who have been shuffled before the dealing. - With the program this is like sending the voters their ballots. The uniqueness of the card represents the vote-code (8, King etc), and the color represents the vote (red or black). With sede, there is only one vote-code though, not two (cards). Go round with two plates, one of which is the voting plate, the other is the discard plate. Each voter can vote black or red on the voting plate, he/she then places the other card on the discard plate. - With the program this is like receiving the ballots who have been filled out. Place the two plates before the voters and shuffle the two stacks or received cards. - With the program, the system doesn't know who is behind an routing address - using anonymous registrations, so the shuffling of cards is like the - actual people accessing their anonymous routing channel and then sending - their ballot back without recognizable data in it, or in the account. - Using non-anonymous registrations, the system shuffles the active voters - file by sorting it. Using non-anonymous voting, the shuffle isn't done. The discard plate's cards are placed aside and get ignored, the voting plate's cards are displayed for all to see. - With the program, this is like publishing all votes. Then the cards can get tallied, the color with most cards on the voting plate wins. - With the program, this is like publishing the tally of the votes. All voters are free to step forward and confirm that their card is where it is supposed to be, they can also confirm if the number of cards is equal to voters in the room. - With the program, the voters can confirm their vote in the results, and they - can confirm if the total number of votes (voting and non-voting) matches - the known total (options exist to deal with unknown totals as good as - possible (some choices have to be made, to either sacrifice some - unmanipulatability, or anonymity). shuffle: Get cards: Vote: Discard: shuffle: Results: person A \ / hearts-2, spades-8 H2 S8 \ / H2 person C X queen-hearts, spades-9 S9 HQ X S9 person D / \ hearts-5, king-spades H5 SK / \ H5 --------- + 2 x Hearts 1 x Spades --------- - Red wins In the sede program, there is but one vote-code per `issue/problem', not two as the above example using cards. One vote-code given the parameter of the vote, and the parameter of the comment. Design (program view): ---------------------- The program is build as a group of programs operating on several user defined directories, which are started by running their name as an argument to a shell wrapper in the $path. Most programs run directly to their end, but some are interactive (debugging, poll-setup, sede-shell). Most programs are zsh-scripts, some are C-coded binaries. The intention is to move all Zsh scripts to Perl. Not all programs are supposed to be user-called because they are doing a specialized sub-job, and are already grouped together in a higher level program. This has been done to make the code better and debugging easier (also for a user if he/she experiences problems, he/she can go down into the lower level details). One of the largest programs is "ballots.c", it is called by the shell script "makes" (and "addvoter") which creates the ballots and everything that is needed to start sending the ballots. Another important command is the command which processes the returned ballots into end-results ("processall"). These two activities are the essentials: creating ballots (etc) (with one command), and then processing the returns (with one command). The results are several lists containing useful information, an html file points to these lists in a html-viewer friendly way. The program falls apart in 4 functional units at this moment: 1 creating ballots, vote-codes 2 receiving voter input: sending/receiving ballots 3 creating results 4 publishing results A function "* register voters" is absent, although in theory there could be some solutions implemented for this, where it makes sense. It is not a necessary part of the program, though. The 5th functional unit is the interface. The commands that make up sede are all "programs" which run in an environment with a lot of sede internal variables set, given some optional arguments or not. From the point of view of the interface, there is no difference between regular shell commands (cp, mv, mutt), and sede commands. Sede commands will fail if they do not find a sede environment, though (token test). These functional units are part of the modularity of the program. The more modularity, the better. The interface between 1-2 is the files created in directory ${SEDE_ROOT_OUT}, in particular the file-names of the ballots and the flags-files. The interface between 2-3 is dumping the returned ballots in clear text form in directory ${SEDE_ROOT_VIN}. The interface between 3-4 are the files generated in directory ${SEDE_ROOT_VOUT}. The interface 4-voters can be several. One option (best supported), is to reformat the results so they can be comfortably browsed with an web browser. Another option is to print the files in ${SEDE_ROOT_VOUT}, etc etc. The interface voters-1 (going back to the start) is the registration of data in the file ${SEDE_ROOT_IN}/c_voters, the "voter registration file". It is a comma delimited list of free to define and use fields. Interface to other programs: a) Every ballot is created with a flags-file, in this file can be put voter dependant flags for use by other applications (see manual) b) Every ballot's filename is postfixed with a voter registration field (the first field). c) Result-lists and configuration files are all plain English and should be simple to parse independently. The result lists have mostly a user-defined content, there are no magical unalterable strings, so it is possible to design ballots with other programs needs in mind. ... There are all kinds of schemes that you can play, doing more or less through the I'net or off the Internet. Doing it more of less anonymous. Flowchart: basic flowchart looks like this: ... input->output->input->output ... These are streams of data, pulsating between voters and vote-administration: -----------------voters---------------------------- \ /\ / ---> direction \/ \/ -----------vote-administration--------------------- Each stream has its own directory in the program. This design permeates the program. It is also possible to put a complaint cycle at the end of the `W', it would then become something like `WV'. That latest input-output stream is not represented by directories, but the data is modifying the latest two directories instead. Similarly, before the first input stream, more input/output waves can be present, but they don't have their own directory either and loop back into the first input directory. -----------------voters---------------------------- \d1 /\d1 /\d3 /\d3 /\d3 ---> direction \/ \/d2 \/d4 \/d4 \/d4 -----------vote-administration--------------------- d=directory Rundown of each leg: \ (voters input towards vote administration): Directory ${SEDE_ROOT_IN}/ First, voters must be registered. This is a data stream from voters towards the vote-administration. The vote administration fills the ${SEDE_ROOT_IN}/ directory with this data, registers the voters. This is an initiation process, after voters have been registered they can be presented with a voting process again and again. \ (voters input towards vote administration): Directory ${SEDE_ROOT_IN}/ After voters have been registered, questions have to be formulated. It can also be that the question was known even before voters got registered. In any case, this data is also put into ${SEDE_ROOT_IN}/. When using SEDE to continuously (safely) poll people, the initiation process will be followed by many poll cycles. \/ (vote administration output towards voters): Directory ${SEDE_ROOT_OUT}/ By running a sede command ("sede makes"), the ballots are created for each voter, they are stored into ${SEDE_ROOT_OUT}/, the first output directory. Along with ballots are also stored databases containing vote codes, flag files, and any voter registration data that is desired. Then the ballots can be actually routed towards the voters. When using e-mail, the email send command is used (which can also encrypt ballots, "sede sendallmail"). Ballots don't need to go out to all voters, voters can get voter-variable ballots. If they have registered against certain subjects, ballots can be programmed to exclude such voters from a vote. \/\ (voters input towards vote administration): Directory ${SEDE_ROOT_VIN}/ Now voters read (decrypt) their ballots and respond to the questions. After this, they send their ballots back, which are received by the vote administration into the second input directory ${SEDE_ROOT_VIN}/. \/\/ (vote administration output towards voters): Directory ${SEDE_ROOT_VOUT}/ Then the results are processed ("sede processall"), and the results of this processing is stored in ${SEDE_ROOT_VOUT}/, which should then be published in its entirety (that directory). Correction cycles: \/\/\ (voters input towards vote administration) Directory ${SEDE_ROOT_VIN}/ When voters complain that their vote was falsely registered, successfully attacked, manipulated or otherwise wrong, they could let the vote administration know this and ask for a change. The vote administration receiving such requests has a couple of levels to verify the identify such a complaining voter, also depending on the anonymity of the registration. 1. (weakest) Is the complaining person use the same routing channel as the ballot. 2. Does the complaining person know the encryption codes (if used) used for the ballot. 3. Does the complaining person know the password that belongs to the vote in question (if such passwords were put into the ballot). 4. Does the complaining person know the registration password of the original voter (if such a password was agreed to). 5. Only if the voter registration is non-anonymous: can the voter verify his/her identity through IDs or otherwise. \/\/\/ (vote administration output towards voters): Directory ${SEDE_ROOT_VOUT}/ If a voter was successfully identified (with enough certainty), and all complaining persons were processed for identity, it would probably be a good thing to look if the changes would change the outcome or just be marginal. In the case of it being marginal there is little to worry about. Results could be regenerated with changes to input made, and voters could be notified of the new results version. In the case of an altered outcome though, things become obviously more tense. I recommend that strict guidelines surrounding complaints be decided even before voting begins, because the complaint cycle is potentially infinite, and itself open for attack. Hence the verifying of complaining persons should be done with great care. This is left to the imagination of the vote administration at this point (\/\/\/\/\/\-...). But whatever happens, voters who see their vote was manipulated, even if they can't or don't want to change it, know what happened. That means: the truth is out there, which is the most basic aim of this system: voter verified voting while retaining anonymity (if desired). Overview input/output legs: To label the different "waves of information", with voting is wave #1: Not all of the below `waves' are necessary, only waves -3 to 2 are essential for results. Maybe the below can be useful to bring some order to the overall process, help you plan it. Importance of the "waves of information" increases when they get closer to 0. Voters <-> Vote Administration Initiation: Asking for voting services: wave -7. -> (lobby, wish) Announcing voting services: wave -6. <- (advertising,lobby) Giving feedback/support: wave -5. -> (reactions) Sending registration information: wave -4. ! <- (instructions) Registering voters: wave -3. ! -> (voter data) Voting cycle: Request questions: wave -2. ! <- (message) *) Giving questions: wave -1. ! -> (communications) *) Sending ballots: wave 0. ! <- (ballots) Voting: wave 1. ! -> (votes) Outputting results: wave 2. ! <- (website) Receiving complaints: wave 3. -> (secure message) Outputting new results: wave 4. <- (website) complaints about complaints: wave 5. -> (secure message) Outputting new results: wave 6. <- (website) complaints about complaints: wave 7. -> (secure message) ...: wave 8. ... Loop_back_to_start-"Voting cycle" *) Taking the view that the "vote administration" is merely a technical body. Another flowchart, with more detail: .---------------------, ( Registration voters.) `---------------------' : .----------------------, ( Making master ballot )<.................... `----------------------' : : : .-------------------------------------------------, : ( Making ballots, "flag files", and code database ) : ( Sede: `makes' and/or `addvoter' commands ) : `-------------------------------------------------' : : : : : Results in ballots, one for each voter, flag-file, one : for each ballot, and records of codes, passwords (etc). : : : : ^ .-----------------------------------------------------------, : ( Sending ballots to voters ) : ( Sede: sendallmail (email) ) : `-----------------------------------------------------------' : :email: :email: :website: :SMS: :telephone :letters : : :encrypted :(CGI-Perl) :specify? :specify? :specify? : : : : : : : : :done :done in :FIXME : : : : :tested :principal :Someone ? :Can make :Unambiguous:Crude : : : : :very short :human read-:space-dot: : : : :ballots. :able vcode :vcode : : : : : :done :done : v v v v v v : .---------------------------------------------------------------, : ( voters receive ballot ) : `---------------------------------------------------------------' : : : : : .----------------------------------------------------------, : ( voters fill out ballot ) : `----------------------------------------------------------' ^ : : : : .----------------------------------------------------------, : ( voters return ballot ) : `----------------------------------------------------------' ^ : : : : : : : : : : : : v v v v v : .-------------------------------------------------, : ( Organization saves returns in electronic form ) : ( in one directory. ) : `-------------------------------------------------' : : : : : .-------------------------------------------------, : ( Compute results ) : ( Sede: processall )<.. : `-------------------------------------------------' : : : : : : : : .-------------------------------------------------, : : ( Publication results ) : : ( (www, book, CD, rolling over tv, telephone ) : : ( computer, ... ) ) : : `-------------------------------------------------' : : :www :telephone :book :CD :... : : : :computer : : : : : : : : : : : : v v v v v : : .----------------------------------------------------------, ^ ^ ( voters browse results ) : : `----------------------------------------------------------' : : : : : / \ : : (yes).....< ok? >......(no) : : : \ / : : : : : : : : : : : : ________________________ : : : / \ : : :<.(yes).< time up for complaints ? >.(no) : : : \________________________/ : : : : : : : : : : : : .----------------------------------, : : : ( voter fill out form ) : : : ( (or otherwise communicate) ) : : : `----------------------------------' : : : : : : : : ^ ^ : .----------------------------------, : : : ( sends it to the administrators ) : : : `----------------------------------' : : : : : : : : : : : .-----------------------------------, : : : ( authenticate ) : : : ( (vote-code+password+registration) : : : ( password) ) : : : ( (depending on vote administration ) : : : ( wishes) ) : : : `-----------------------------------' ^ ^ : : : : : : : : : .----------------------------------, : : : ( adapt received votes for voter )...>....: : : ( (or amend results otherwise) ) : : `----------------------------------' : : : : : : : ____________________________________________ : / \ : < more voting to do for the registered voters ? >.....(yes)................: \_____________________________________________/ : (no).......end. To prevent looping infinitely over complaints, a date for latest reception for a complaint about a vote can be set, and the correction cycle be run one time only (for all complaints), after which any errors detract from the credibility of the vote as a whole. If this is not dramatic (below the margin between the options), then one can live with a few errors, if the rate of errors remains dramatic automatically the whole process has lost credibility. One could decide to try again and do something different to prevent all the errors (?).