Prev Table of Contents Next


TDP Notes
Version 0.4


Section 3

[ It should be noted by anyone reading this document that it consists of ideas that may or may not be implemented by the Techno Democracy Project. It was intended only as a collection of brain storming notes, not as a blueprint cast in stone. Regardless of the language used to describe the ideas, they are all merely options for TDP, and others, to consider. As time as goes by, it may become apparent that some, many, or all of the ideas are not suitable for implementation. However, either way, this document can be a catalyst for further thought and discussion on the topics covered. ]


TD & TDS Definition

One of the main goals of the 'Techno Democracy Project' (TDP) will be designing and building a world-class online voting system. But there will be other goals related to other types of online systems which can support 'Techno Democracy' (TD). A definition for these systems, which will be generically referred to as 'Techno Democracy Systems' (TDS), could be 'any online, computerized system which supports, enables, or enhances one or more processes in a democracy-based government'. This is a broad definition which goes well beyond electronic voting systems and could potentially include just about any process in any democracy-based government (organizational, local, state, provincial, regional, national, continental, or International) which can be computerized.


Tools & Mechanisms

To start out with, one of our main focuses will be on electronic voting systems. But with time and additional resources, we will be able to venture into many other types of TD systems. Here is an overview of some other types of TDS which could potentially be built by TDP.

Legislative Branch Tools
Executive Branch Tools

The Executive Branch of a government, with its various offices, agencies, and ministries, creates policy and decisions on a regular basis which are, in effect, minor pieces of legislation. These offices, agencies, and ministries operate under 'umbrella charters' issued to them by some previous piece of legislation.

Even though the General Public is not directly involved with creating Executive Branch decisions and policy, the General Public is directly affected by these actions. Whether it's the agency implementing the Tax System, managing the Social Welfare program, over-looking Natural Resources or some other governmental function, everyday people are affected by these agencies' decisions and want to have input into their policy creation, implementation, and modification.

TDS tools could be created to help these agencies communicate with, and interact with, the General Public. This would allow these agencies and ministries to operate in an Integrated way with the General Public, instead of in an Isolated way.

However, it should be noted, that the purpose of Executive Branch TDS should *not* be to micro-manage the Executive Branch of a Government. Micro-managing our public officials will not help them do their jobs, but will instead make their jobs much harder. A productive balance will need to be found to maintain a healthy level of Public input and a reasonable degree of empowerment for our public officials.

Governmental Executive Branches would need to be studied to determine what types of TDS tools would be appropriate and beneficial to create and be utilized with this branch of government. All votes cast on issues being handled by an Executive Branch would be for guidance-purposes only, and would be non-binding in nature.

Judiciary Branch Tools

The Judicial Branch serves as an important check & balance to the other two branches of government. However, just as with the Executive Branch, the Judiciary does not work best in a vacuum. Interacting with the General Public, as opposed to being Isolated from it, helps the Judiciary interpret law in ways relevant to our rapidly changing world.

Just as with Executive Branch TDS, Judicial Branch TDS would be for guidance-purposes only and would be non-binding in nature. The exact requirements and purposes of Judicial Branch TDS will need to be determined at a future date and time.

PoliBots & GovBots

Another TDS concept, which is a bit 'out there', is 'PoliBots'. In computer software circles, software 'robots' (which perform specific pre-defined functions autonomously) are referred to as 'bots' or 'agents'. 'PoliBots' would, as the name implies, be 'political bots' -- able to perform political and TD functions in an autonomous or semi-autonomous way.

In small legislatures, PoliBots would be merely a novelty. However, once the number of Voters, Advisors, and/or Representatives moves into the hundreds, PoliBots become useful. When Voters, Advisors, and/or Representatives number in the thousands or millions, PoliBots become essential. Large-scale groups simply can't support all the interaction needed for a properly functioning legislature, without the use of assistants - either human or computerized.

Much of the above-mentioned TDS functionality could be built into specific PoliBots. For example…
Other Types of Polibots - could be built. As the cliché goes, 'necessity is the mother of invention'. So, whenever it becomes apparent that a specific type of polibot would be useful, somebody will build it.

Also, just as with the Vote-Trading and Deal-Making tools, some types of Polibots will probably be controversial and not universally welcomed. TDS will need to have the ability to 'turn off' and/or 'block' specific types of Polibots which are not welcome in specific voting jurisdictions or legislative bodies.

GovBots - would also be software robots, just as PoliBots are. However, they would be for performing tasks related to government data and government services, instead of relating to political processes.


System Sizes

Different sized voting systems are needed for different purposes, but they all share common voting functionality. For this document, it's useful to break voting systems down into three general categories -- High-End/Industrial-Grade, Medium-Sized/Organizational, and Low-End/Personal-Family-Workgroup.

[ TDP may not produce different systems, based on system size. It is more likely that a single system will be built so that it is highly configurable. Then specialized configurations, complete with unique install and usage procedures, would be created for different purposes. ]


Targeted Functionality

The functionality which is the end-target of our efforts is a TD voting system which can handle both Occasional/Electoral and Ongoing/Legislative types of voting in the same system. The back-end systems should also be able to handle votes from High-End, Medium-Sized, and Low-End systems concurrently. Additionally, the back-end systems should be able to handle voting traffic from Direct-Democracy, Representative-Democracy, Advisory-Representative-Democracies, and Advisory-Democracies concurrently.

This targeted functionality points to a design which has customized (or customizable) front-end clients and servers, feeding into standardized back-end servers.

Ideally, all TDP systems should be easy to download, setup, configure, use, and monitor. All TDP systems should be usable via the Internet, a LAN, or a WAN -- either with a web-browser or with a separate piece of custom-built client software.


Voting Issues

The book "Campaign and Election Reform" written by Glenn H. Utter & Ruth Ann Strickland (c.1997) has some excellent material on problems encountered with both traditional voting systems and newer computerized voting systems. Here is a brief summary of some of the issues brought up in that book.

Open Voting Issues Secret Voting Issues Election Officials Issues Unlawful Actions Issues Other Voting Issues Computerized Voting Issues Traditional Safe Guards Against Fraud Summary of Voting Issues A more complete treatment of this topic is available by borrowing or purchasing a copy of the "Campaign and Election Reform" book.


TDS Assumptions

  1. Murphy's Law

    Anything that can go wrong with the system or its processes, will go wrong. This should be expected and prepared for.

  2. Cracking Effort ~ System's Influence

    The amount of resources and effort which may, potentially, be brought to bear on cracking or manipulating a TDS will be in direct proportion to how much various people or organizations have to gain or lose by what is being governed by that particular system.

  3. Every Element is Expendable

    Any or all versions of any part, component, system, design, configuration, programming language, operating system, crypto key, or crypto algorithm can be compromised at any time, by accident or by skilled & concerted effort.

  4. All Crypto Will Be Broken -- Eventually

    With the advent of increasingly more powerful computers and increasingly more sophisticated cryptography techniques, it's just a matter of time before any and all present-day encryption is broken. This should be expected and accounted for when designing and building TDS.

  5. Systems Containing Voter Identities are Potential Threats

    Any system containing information that can be traced back to an actual Voter, is a potential threat to Anonymity, Privacy, and Voter Security - even if that information is in encrypted form. Extra care should be taken to minimize the number of systems containing Voter identification information and to secure the information as strongly as is possible.

  6. All Information in any One System, Facility, or Region which is Connectable, will be Connected

    This assumes that a System, an entire data center Facility, or an entire Region (state, province, or country) has been compromised and that all the information on the system(s) affected will be pooled and analyzed. And, any information on the affected system(s) which can be connected together, will be connected together. In other words, if a particular Voter's identification, their Voting Preferences, and Actual Votes are all contained in any One System, Facility, or Region, then they are vulnerable to being connected together - even if they are all encrypted with different crypto keys and algorithms.

    This, obviously, is a super-paranoid assumption. But, if we can design and build TD systems to handle this assumption without being compromised, then we'd have very secure systems. The one situation which this wouldn't handle is if different Regions cooperated with each other and pooled their resources together. But, the TDS data has to be stored *somewhere*.

    The 'cooperating Regions' problem could be addressed in other ways, such as tracking which Regions would be most likely to cooperate with each other & placing them in Meta-Regions. The system could then treat each Meta-Region in the same way it treats individual Regions.

  7. All Voting Data Will Be Stored -- by Someone

    This is not to say that official TDP systems will be storing voter information. But, it is to say that, when transmitted over the publicly-accessible Internet, TDS data becomes available to be stored by any person, group, or government which has sufficient access.

    In and of itself, this is not a big deal since all the data will be encrypted. However, when combining this idea with the assumption that 'all crypto can be broken', this assumption becomes relevant.

    In combination, they point to the possibility that present-day encrypted voting data could be stored -- and then decrypted at a later date, when the data's encryption becomes obsoleted by newer technologies and techniques. Whether that storage period would be 5 years or 50 years is unknowable. But, with the rate of technological innovation these days, it may be a short enough period of time to be a threat to an individual voter's personal security -- if the decrypted voting data were to fall into the wrong hands (such as a corrupt government, corrupt military, or a politically active crime organization).

    This, also, is a paranoid assumption. But, if we can build TD systems which can stand up against this sort of breach of privacy, then we'll be doing well.

  8. Earning Peoples' Trust

    TDS need to earn the trust of experts & novices alike, as well as the trust of most of the people on the Very-Gullible-to-Super-Paranoid Continuum.

  9. Easy-to-Use, Intuitive, & Metaphor-based

    TDS need to be easy-to-use, intuitive, and must use commonly understood metaphors.

  10. Speed of Change ~ Size of Political System

    The larger a Political System, the longer it will take to adopt TD technology.

  11. Amount of Positive Potential ~ Size of Political System

    The larger the Political System, the more good which can be accomplished by improving that System.

  12. The Best Way to Industrial-Grade Usability

    The best way to build Industrial-Grade TDS which the people of the world will trust & will use, is to...
    1. build a best-effort prototype;
    2. run it in parallel with real-life political systems which it could ...
      1. be integrated with, or
      2. replaced;
    3. continually figure out how it can be improved;
    4. continually fix any problems & evolve the system into a better & more powerful tool, until it is fully ready to be used by real-life political systems;
    5. continue to improve it, even after it is real-life-ready.

  13. The Best Way to TDS Adoption

    The best way to get a Techno Democracy Systems (TDS) to be adopted by people is to…
    1. get them to use it in 'parallel' mode;
    2. get them to experience how much more power they have with the TDS than they do with their traditional system;
    3. create a community of people who truly believe in the TDS;
    4. get people to create content for their own organizational, institutional, local, regional, national, and International political systems;
    5. get people to spread the word & get more people involved.

TDS Principles

  1. Highly Redundant

    If any piece of the TDS malfunctions for any reason - naturally-caused or human-induced - the rest of the system will continue on unaffected with full integrity.

  2. Highly Secure

    1. Every feasible security precaution will be taken.
    2. All production systems will be tested and re-certified on a regular, ongoing basis.
    3. Every security expert in the world will be able to review, study, and openly evaluate all systems, code, procedures, and relationships -- due to the open-source nature of the project.
    4. TDP will try to ensure that no voting system in the world will be more thoroughly reviewed by more experts than TDP's systems.

  3. Privacy, Anonymity, & Personal Safety

    1. Privacy & anonymity will be protected everywhere it is possible.
    2. It is understood that in some parts of the world people's safety will be at risk if their votes are not kept strictly confidential & anonymous. This should be kept in mind as the systems' privacy mechanisms are designed, implemented, & maintained.

  4. Highly Diverse

    1. The system is to have a standard set of requirements, a standard high-level design, & standard interfaces. But, it is to be implemented with components which will be of different low-level designs, written in different programming languages, and targeted to work on different operating systems.
    2. No voting stream in any given set of 'voting streams' shall be identical in components, configurations, facilities, regions, or groups.
    3. Each 'phase' or 'level' of any given set of 'voting streams' shall consist of no less than 3 different brands of components; which operate on no less than 3 different operating systems; in no less than 3 different facilities; in no less than 3 different regions; and on systems which are controlled by no less than 3 different groups/organizations. We will consider this a 3-path system. A 5-path system is preferable, but will not be feasible until there are enough TDP-certified servers available to accomplish it.
    4. No more than 1/3 of any 'voting stream' or any set of 'voting streams' may use any single brand of component, operating system, facility, region, or group/organization.
    5. Any given component, system, brand, version, operating system, facility, region, or group/organization needs to be expendable & able to be routed around, at any place in the overall system, at any time.

  5. Complete Transparency & Auditability

    1. This Principle is self-explanatory, but is not to be implemented in any way in which would compromise any individual's identity or votes.
    2. TDP should have its own auditing & monitoring groups. But this role should be opened up and made available to other, widely respected, organizations also.
    3. Each voter could be given x number of 'validity checks' for each issue they vote on. These validity checks can then be 'donated' to the voter's choice of vote monitoring organization(s) to use for verifying the integrity of the vote.

  6. Conflict of Interest

    Any Conflict of Interest situation, related to any of TDP's voting systems in Development or in Production, should be made public

  7. Internationalization

    TDP's systems should be customizable to any language or culture.

  8. Malleable

    TDP's systems should be customizable and/or configurable to fit most/all democracy-based political systems.

  9. Open Source

    TDP's software is to be 100% open-source, so they can be inspected by anyone.

  10. Free or Low Cost

    TDP's software is to be Free or Low Cost to anyone and everyone.

  11. World-wide

    TDP's software is to be available world-wide.

  12. Amorphous & Impervious

    TDP's implemented network of TD systems is to be amorphous and impervious to complete destruction. Similar to how the Internet was designed in a way which enables it to withstand a nuclear war. Whether it was intentionally designed this way or not has been debated. However, the fact that it has an impossible-to-completely-destroy-without-destroying-most-of-civilization-along-with-it property is not debated. If part of the Internet is destroyed, the rest of it routes around the destroyed section and continues on unaffected. Same idea, but implemented in a world-wide system of voting system servers, etc. and allows for whole sections of TD servers to be excluded for any variety of reasons -- including the servers being destroyed, corrupted, technical problems, International political tensions, etc.

  13. Forkable

      This TDS Principle refers to two different things.

    1. First, for the Source Code, since it will be under an open-source license, it will naturally have the option of being forked -- if that is deemed necessary. This protects everyone's investment into the systems and insures that they will continue on. Rick Moen has written an excellent article on LinuxCare entitled "Fear of Forking". It's currently available here, but may get moved to the archives. It was published on November 17, 1999.

    2. Secondly, for the world-wide network of voting servers, if TDP doesn't sufficiently provide the world with the TD and voting services that are needed, then the individuals and organizations which voluntarily run TD servers in the world-wide TDP network have the option of joining a different TD network. This protects the interest of individuals and democracies world-wide, and allows for TDP to be replaced if it doesn't do a good job.

Build & Use

Part of the TDP process for building a world-class voting system, is to follow a "build & use" strategy. Using TDS Assumption #12 (Industrial-Grade Usability) and TDS Assumption #13 (TDS Adoption) as a base, TDP would build the TD systems. Then, they will be put into production (possibly using one of the Netocracy domain names). This will allow real-world testing of the TD systems, in as close to a real-world TD situation as we can come up with.


Evolutionary Development & Gens

It's not uncommon in software development that after a system is built and in use for some time, that a better design for the system becomes apparent. Also, in the course of starting a new open-source software (OSS) project, it is normal to have only a few people contributing to the project early on. Then, if the project catches on, contributors join the project over time and expand the project's resource pool. TDP can handle both of these phenomena by using an Evolutionary Development approach.

With Evolutionary Development, we can pre-plan each TD system's evolution as a series of Generations of that system -- or Gens for short. Each Gen could tackle a progressively larger and more complex version of the system. By using experience gained from previous Generations of the system, the new Gen could be re-designed, re-shaped, and re-built to be better, faster, more stable, more secure, or whatever.

Each new Gen should be considered a complete re-design and re-build of the system from the ground up -- if that is what's needed to build the best TD system possible. The key is to do whatever it takes to continually be building the best TD systems around. If that means only a minor re-design from one Gen to the next, then so be it. However, if that means a total re-design (like the Mozilla team did with the Netscape browser), then so be it. Initially at least, re-designing and re-building systems from the ground up will be a dauntingly large undertaking. But, over time that should change. Since the overall design of a system will improve over time -- major over-hauls of that system will be increasingly less necessary.

Also, initially, we can plan Generations to be quite focused -- only one platform and one programming language. Then, if resources increase, we could expand out in future Gens to multiple platforms and multiple programming languages.

[ Join the TDP email list to keep up-to-date with the latest news from TDP. ]

Prev Home Next
     
  Copyright 1998 - 2001 by Thom Wysong