PollingVotingNotesAudioguy

AudioGuyWorkNotes - parent CommunicationSystems

• http://anonscm.debian.org/gitweb/?p=users/srivasta/debian/devotee.git;a=tree;f=examples;h=3c2da2c7524b14ecca52f21d0f961f72ae670c22;hb=refs/heads/master
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470995
• http://www.debian.org/vote/
• ProposedSolutionForTheCommunityPoll

Notes on the various polls of concern

(from the staff vote system, for reference, to have something to refer to)

There are really three completely different polling/voting systems being discussed: The poll on the main Soylent site. The need for a poll for the registered users of Soylent for major issues like the name change The need for a way to poll staff on issues that allows everyone to participate

1. The Slash Code Poll

This is the perl code on the slash site that is used for quickie polls. It is very much an 'ad hoc' system, and is open not only to registered users, but to anyone that goes to the site. It is easy to game this poll, it was never intended to be anything more than what it is. There has been some discussion of improving it in various ways. However, any attempt to improve it will at the least require some serious coding effort to integrate the changes into the rather complex Slash code system. Any attempt to actually make it MORE than an ad hoc poll, would face some extremely difficult problems related to armoring the code against cheating and abuse.

2. A poll for registered users for significant input on major issues

As a community based site, we clearly need some way to take the pulse of the community, in particular the registered users who support us. The most recent case is that of looking for name suggestions for the site, and voting on them.

The solution needed for this need not necessarily be integrated into the site, as it addresses a smaller group who we have means of contacting. So the programming problem is somewhat simplified for this case. However, with such a large group of people, there is still much potential for gaming the system and attempts to break it. So this is not a trivial problem to solve, and a number of approaches are being looked at. Whatever we pick or write needs to be pretty robust.

3. A poll/voting system to take the pulse of just our staff

Staff has it's own unique problems in this area which are completely separate and quite different from the two described above. (Staff voting system created and intended to solve this one)

Requirements for the #2 system - for registered users, 'our community'

• Needs to be available only to registered users
• Must allow only registered users to vote
• Must allow only one vote per user
• Must not be possible to 'fake' a user and vote, or otherwise 'hack' the vote
• Must be understandable to a larger group of people than just staff
• MAY need a way for users to submit poll items, or may not.

Additional requirements for specific issue of domain name suggestions and voting

In addition, we have an immediate issue which has some unusual requirements, which may be unique to this issue.

• Need way for domain name suggestions to be submitted without out opening this up to evil domain name squatters trying to profit off us.
• Need a way to insure we have clear title to the name selected

Quick look at Devotee

This is just some quick first impressions, could be wrong. Want to have NC take a look at this as I think he has some direct experience with it. (and if you do nc, - this is a wiki - just edit in your changes or notes here)

Plusses

• Already written
• Apparently in current use at Debian
• Source available
• uses email
• uses ldap
• uses crypto keys, strong auth
• bash scripts and perl
• uses ranked voting, Condorcet method

Minuses

• Code base looks pretty old, most recent 2008 or so, may have problems with perl libs (same age as slash code). Am not personally excited about maybe having to debug old perl code ;-)
• seems very specifially designed for the Debian system of developers, who have clear access privileges
• ldap - not sure we want thousands of people in our ldap database with their fequent changes, and if a separate ldap was used, would be a duplication of the slash database in many ways
• managing crypto keys for some developers is one thing, for thousands or tens of thousands of users strikes me as an administrative nightmare
• Does not seem to be in their current base, at least apt-get was unable to get it. But my apt-get fu may be bad, do not use debian much. (have it on my remote server)

The philosophy here in the code was actually very close to what I am doing with the staff voting thing, so similar it caused me to laugh at one point. There really aren't that many ways to do simple voting. ;-)

possible solution to the auth problem

Idea #1

My first thought was to use public/private keys.

The crypto itself works fine.

The problem is generating the keys. I tried this first on my remote server - virtual server. Never was able to get eough entropy to generate even ONE key there.

Tried a server at home, same problem, finally hooked up a keyboard to it, and did finally get a key, after about a minute.

Doing thousands of these? Forget it.

The programs can maybe be recompiled to use the lessor random number generator, but it is still not really very fast.

I'm chalking this up as BAD IDEA #1

Idea #2

Use md5sum of customer information like name, userid, other stuff that does not normally change.

These are long enough, and non-sequenntial enough:

0555a0b97becd0e3beac6483548a6d23

that it would be hard for someone to send in fake votes by guessing at valid id numbers.

In addition, these could change for each vote by adding in the poll name to the sum. That way each voter would have a uniq number, only used once, but verifiable.

Send this in the outgoing emails, each number can only vote once. Do what Devotee does, and send back a confirmation, which should help detect any shenanigans like impersonating other users.

Simple, and requires no real crypto.

names

However, I think -that- name may be better used for the other -public- voting options. So I am thinking something like this:

vote.soylentnews.org - for user base voting system
pollbooth.soylentnews.org - in case we ever need it for the public poll
poll.soylentnews.org - for this staff poll.

> vote.soylentnews.org - for user base voting system 
> pollbooth.soylentnews.org - in case we ever need it for the public
> poll poll.soylentnews.org - for this staff poll.
>   

Hrm ....

For staff only, it probably should just live under
staff.soylentnews.org. If we use it publicly, then my option is vote.
<pre>

OK, so:

staffvote - for staff

vote - registered users

poll - the thing on soylent pages.


==User Database==
<pre>
DROP TABLE IF EXISTS users;
CREATE TABLE users (
        uid mediumint UNSIGNED NOT NULL AUTO_INCREMENT,
        nickname VARCHAR(20) DEFAULT '' NOT NULL,
        realemail VARCHAR(50) DEFAULT '' NOT NULL,
        fakeemail VARCHAR(75),
        homepage VARCHAR(100),
        passwd CHAR(32) DEFAULT '' NOT NULL,
        sig VARCHAR(200),
        seclev mediumint UNSIGNED DEFAULT '0' NOT NULL, /* This is set to 0 as a safety factor */
        matchname VARCHAR(20),
        newpasswd VARCHAR(8),
        journal_last_entry_date datetime,
        author tinyint DEFAULT 0 NOT NULL,
        shill_id TINYINT UNSIGNED DEFAULT 0 NOT NULL,
        PRIMARY KEY (uid),
        KEY login (nickname,uid,passwd),
        KEY chk4user (realemail,nickname),
        KEY chk4matchname (matchname),
        KEY author_lookup (author),
        KEY seclev (seclev)
) ENGINE=InnoDB;

Use for md5sum :

nickname, uid, realemail + this votes short nametag (identifier)

For a FLAG as a registered voter, use sig, with =NAMEVOTE= in it. First thing.