Most electronic voting systems seem to cut people out of the equation. With them, the democratic tradition of voting goes from being "of the people, by the people" to being "of the vendors, by the technology".

The TDP Voting System, while using technology, is none-the-less Powered by People.

The system is to be designed and built using an open, inclusive process. While an initial overview of the system is laid out here, the detailed design, source code, and documentation are to be created using a hybrid partially-open/partially-closed approach - utilizing input from all who care to offer it. Additionally, the system is to be owned "by the people" (or by a non-profit organization acting on the public's behalf) - not by a for-profit company.

This is in contrast to the common approach being used today - where a voting system is built, owned, and controlled by a small group of people, at a company attempting to generate revenue and profits off its proprietary, closed, voting technology.

Decentralized groups of people, providing valuable checks & balances, are used pervasively throughout the TDP voting system design, just as they are used throughout modern democratic governments. The democratic tradition of maintaining integrity in government, by using decentralization, procedural transparency, and public auditability, is maintained with this Voting System - not replaced by mathematical formulas and a "just trust us" approach.

One positive aspect of having Ballots in electronic format is that it allows those Ballots to be counted in many different ways, using alternate vote counting methods. In studies of alternate voting and counting methods, it seems that political scientists tend to process a relatively small number of test Ballots through a simulator than counts the votes in different ways [20,21,22]. These small batches of test Ballots provide valuable information about characteristics of each alternate voting method. However, the Counting Servers could be made to count actual voted ballots using the alternate vote counting methods. This would provide substantial and beneficial information on what effect a change to a jurisdiction's vote counting method would have, before the jurisdiction actually commits to the alternate counting method.

Yet another possibility is studying voting patterns is the use of Anonymous Profiles of Voters. Each Voter who chooses to participate would voluntarily fill in demographic information (age, gender, ethnicity, postal code, income, etc) about themselves in special fields on their ballot.

The demographic options would be put into groups, where possible, to lessen the chance of privacy violation. For example, 'age' would be collected in ranges … 18-24, 25-29, 30-34, 35-39, etc. Income, ethnicity, and postal code would also be grouped when necessary. Once the demographic groupings are established, they would be mixed and matched into all their various combinations. Each possible combination would be considered a single Anonymous Voter Profile. Each Profile would be assigned a unique Profile ID.

When a Voter enters their demographic information on their ballot, the information is analyzed and replaced with the Profile ID for whichever Anonymous Voter Profile that Voter fits within.

When the ballots are processed, the information linking each specific Voter to their Ballot is stripped away. However, their Anonymous Voter Profile ID would remain with their Ballot. The Voter Profile ID would be attached to each of the Votes on a Ballot, when processed by the Counting Servers. This way, when the Vote Totals are analyzed, everyone will have a much better idea of which parts of the population voted and, as a group, who they voted for. This could lead to a better understanding of why people vote the way they do and why other people don't vote at all.

Additionally, in the future, this could prevent a repeat of all the finger pointing and speculation on demographics that followed Arizona's 2000 US Presidential Primary. That election was conducted, in part, using Internet Voting. It was controversial. There was much speculation. However, there was no hard data. Using Anonymous Voter Profiling would allow hard data to be collected from actual voters, while they're voting. If discrimination actually happens, it should show up in these numbers. It seems that this could provide substantially more accurate numbers on Voter demographics than estimates and guesses based on questionable data.

The log - or transcript - of all inputs and outputs that occur during a voter's voting session would be contained in a Raw Data Ballot. This log would need to be sufficiently detailed to allow it to be fed into a simulation program designed to allow Vote Officials to watch a Replay of what the voter was doing in their Voting Session. Since the Raw Data Ballots would not be decrypted until after all voter identity information has been stripped from them, they would be anonymous ballots by the time Officials view the Replays. Voting Session Replays would work just like a digital VCR - fast forward, reverse, slow motion, freeze frame, zoom in, zoom out, and (maybe) John-Madden-esque tele-strator capabilities. The purpose of Voting Session Replay would be to give Vote Officials one more tool in their quest to discern voter intent and to insure the integrity of voting events.

Extensible Markup Language, or XML, has been rapidly accepted by industry as a tool for representing data structures in a technology-independent manner. When a common type of data needs to be exchanged between heterogeneous systems, it is not uncommon for a specialized version of XML to be created for the task.

It seems that creating a vendor-neutral, technology-neutral, and system-neutral version of XML for Voting would be beneficial to society.

VoteXML could enable standardized testing files to be created. It could enable components from different system-creators to work together (this would depend on the suitability of specific voting system designs to work with other voting systems). During or after completion of a voting event, compliant voting systems could output their voted-ballot images and log files in standardized VoteXML format which could then be culled through by System Administrator tools and Citizen Observer tools to look for irregularities, problems, and errors. Voter privacy and the integrity of the voting event would need to be thoroughly protected with any such setup.

The compliant voting systems would not need to internally use VoteXML data structures. They would simply need to import VoteXML data into their internal format and export internal data out to VoteXML format.

In line with this vision, TDP has obtained the rights to the VoteXML domain names. Anyone interested in participating in the creation of VoteXML is invited to send an email with name, contact information, and experience with voting systems, XML, and/or standards creation to votexml@technodemocracy.org. Individuals possessing experience relevant to the creation of a VoteXML draft standard will be invited to participate in the very early stages of its development.

Any major news pertaining to the creation of a VoteXML standard will be announced on the TDP mailing list.

[ On 31 March 2001, while researching a link to include in version 0.4 of this document, I happened on to this announcement. It is dated 29 March 2001 and is a Call for Participation for the creation of "Election Markup Language" (EML). When I saw the timestamp I was rather amused to see that this announcement was apparently posted only ** 8 hours ** after I registered the VoteXML domain names (and many weeks after I had first considered doing so). I'm sure they had no knowledge of my efforts and I certainly had no knowledge of theirs.

Upon investigation, these appear as if they will be separate efforts. One difference between these two efforts is that "Election Markup Language" is, obviously, targeted specifically to elections. VoteXML is intended to be for any type of electoral or legislative voting event - including for direct democracy and for legislators voting remotely on legislation from their home district. This last scenario would allow legislators to remain close to their constituents during more of the year than is possible when they are required to vote in-person in some far away, legislative chamber. Remote Legislative Voting would, most likely, be conducted over a closed, wide-area-network that connects all the legislators in their home districts with the centrally located, legislative voting system.

Something else to notice is that, even though the umbrella organization which is facilitating the creation of EML "provides an open forum", if you read the details you realize that it costs a minimum of $250 USD per year for individuals, and up to $9,500 USD per year for organizations, to become a voting member of the Technical Committee which will be creating the EML specification.

Additionally, it is worth noticing that the EML creation process will rely extensively on face-to-face meetings and teleconference calls. For those who are based close to Garden City, New York, USA this will be no problem. However, anyone not based in North America who wishes to be a part of the EML creation process will need to incur either substantial travel expenses, or non-trivial costs from transcontinental telephone calls, to participate in the meetings. And, this doesn't take into account the challenges that dialing into a conference call from any of 24 different time zones would present.

This particular process seems well suited for the creation of standards used by American or Canadian companies. However, it is heavily biased in favor of well-financed, North Americans. Because of this, we don't believe it is an appropriate or beneficial process to use for the creation of any standard upon which voting, democracy, government, or public interest technology is to be based.

The VoteXML creation process will address these issues by following a process closer to those used to create open/free software and IETF standards - relying heavily on email and the web, allowing anyone to contribute who can do so substantively.

Those individuals who are experienced with voting systems, XML, and/or the standards creation process, are encouraged to become involved with creating VoteXML. To do so, send an email to votexml@technodemocracy.org with your name, contact information, and a description of your relevant experience. Those people who are only interested in being updated on any major news regarding the creation of VoteXML are encouraged to subscribe to the TDP Mailing List. -TW ]