CSC 379 SUM2008:Week 5, Group 2: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 7: Line 7:
* http://courses.ncsu.edu/csc379/lec/001/lectures/wk14/lecture.html
* http://courses.ncsu.edu/csc379/lec/001/lectures/wk14/lecture.html


==Introduction==
==Voting Systems==


The voting apparatuses that have been employed in any democratic election process, including ballots, lever systems, and DRE (direct-recording electronic) voting machines, have a history of intrinsic vulnerabilities and illusory public trust. To fully understand why all voting apparatuses are flawed, one must know the design specifications, the basics of which are summarized neatly in Michael Shamos, Ph.D.'s six commandments for voting system design (listed in order of consensual public importance):
The voting apparatuses that have been employed in any democratic election process, including ballots, lever systems, and DRE (direct-recording electronic) voting machines, have a history of intrinsic vulnerabilities and illusory public trust. To fully understand why all voting apparatuses are flawed, one must know the design specifications, the basics of which are summarized neatly in Michael Shamos, Ph.D.'s six commandments for voting system design (listed in order of consensual public importance):

Revision as of 03:04, 10 August 2008

Open Non-Proprietary Technology vs. Closed Proprietary Technology

The issues surrounding electronic voting have highlighted the concerns of use of open non-proprietary technology vs. closed proprietary technology. On the one side, closed proprietary technology allegedly safeguards voting security by making it impossible for outsiders to discover vulnerabilities by analyzing the code. On the other side, open technology encourages more eyes to look over the code, and may find vulnerabilities in advance, in time to correct them. What bearing does this discussion have on other types of software systems? Should other systems with high social value also have open non-proprietary licenses to increase accountability, or do the risks of open licensing outweigh the benefits?

Examine how the experience with electronic voting applies to other critical software systems (e.g., software used for port security, handling medical records, or managing a payroll). What are the costs and benefits of open non-proprietary technology vs. closed proprietary technology for such applications? Are there applications where one or the other should clearly be used? Are there applications for which neither is appropriate? Please explain your answers.

Voting Systems

The voting apparatuses that have been employed in any democratic election process, including ballots, lever systems, and DRE (direct-recording electronic) voting machines, have a history of intrinsic vulnerabilities and illusory public trust. To fully understand why all voting apparatuses are flawed, one must know the design specifications, the basics of which are summarized neatly in Michael Shamos, Ph.D.'s six commandments for voting system design (listed in order of consensual public importance):

  1. Thou shalt keep each voter's choices an inviolable secret.
  2. Thou shalt allow each eligible voter to vote only once, and only for those offices for which she is authorized to cast a vote.
  3. Thou shalt not permit tampering with thy voting system, nor the exchange of gold for votes.
  4. Thou shalt report all votes accurately.
  5. Thy voting system shall remain operable throughout each election.
  6. Thou shalt keep an audit trail to detect sins against Commandments II-IV, but thy audit trail shall not violate Commandment I.[1]

Successful implementation of such a system is a practical impossibility. The chief contradiction lies between commandments I and VI: one cannot successfully audit a set of votes in which each voter's selections are guaranteed to be secret. That is, the disconnect between vote capture and vote reporting, as required by the primary commandment precludes a reliable audit. And so the historical solution to this dilemma has been to always maintain the secrecy of each vote, while relaxing the audit requirement to allow the use of merely "good-enough" solutions.

Proprietary Systems

Advantages

A leading proponent of proprietary software is Microsoft. They argue that requiring users to pay for software as a product increases funding for the research and development of software. They claim that per-copy fees maximize the profitability of software development.

When it comes to market revenue, closed source software especially creates greater commercial activity over free software.

Disadvantages

  • Closed systems require the public to trust a private entity to have done due diligence in manufacturing a robust technical solution, and to trust that the system is impervious to tampering by maligned parties.
  • Keeping system design closed to the public does not necessarily prevent interested parties from viewing that design; lax security policies, outright bribery, or simple carelessness may lead to public exposure of that design.

Open Source System

Advantages

An obvious benefit is that open source code, available to all, is usually free.

Another convenience of open source code is that bugs are usually found faster and can be fixed by the user(s) who comes across it. Instead of waiting for a new release of the software with the bug corrected, open source code can also be redistributed to bring a corrected version to everyone immediately.

Support for open source software, just as the software itself, is easily accessible. With so many people able to view the code, theoretically any number of them could offer support.

Possibly the biggest advantage of open source software is the fact that everybody has the right and ability to modify and tweak the source code. This allows for implementation in other software and adaptability to a changing environment.

Disadvantages

  • If a system design is open to public inspection, then anyone is free to locate vulnerabilities within that system without reporting them to codebase maintainers; those vulnerabilities could be used for private gain.
  • Even if a published system design is purported to be used; that does not guarantee that it is so. It is feasible that an organization could claim to use published source code, but then use a different system altogether in the actual implementation.
  • One of the strengths of open source projects is that more eyes seems to imply better code, but in highly specialized systems, the general public may lack the technical expertise to properly evaluate or improve them. Certainly basic bugs and glaring security flaws may be addressed by the public, but more nuanced vulnerabilities require highly skilled minds to detect.

Resources