PollingVotingNotesAudioguy - Revision history

AudioGuy at 18:56, 7 April 2014

2014-04-07T18:56:09Z

← Older revision		Revision as of 18:56, 7 April 2014
Line 162:		Line 162:
	Use for md5sum :		Use for md5sum :

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

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

AudioGuy at 03:51, 7 April 2014

2014-04-07T03:51:48Z

← Older revision		Revision as of 03:51, 7 April 2014
Line 132:		Line 132:

	poll - the thing on soylent pages.		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;
			</pre>

			Use for md5sum :

			nickname, uid, realemail

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

50.45.172.72 at 21:39, 30 March 2014

2014-03-30T21:39:47Z

← Older revision		Revision as of 21:39, 30 March 2014
Line 124:		Line 124:
	staff.soylentnews.org. If we use it publicly, then my option is vote.		staff.soylentnews.org. If we use it publicly, then my option is vote.
	<pre>		<pre>

			OK, so:

			staffvote - for staff

			vote - registered users

			poll - the thing on soylent pages.

50.45.172.72 at 21:37, 30 March 2014

2014-03-30T21:37:37Z

← Older revision		Revision as of 21:37, 30 March 2014
Line 104:		Line 104:

	Simple, and requires no real crypto.		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:
			<pre>
			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>

AudioGuy at 15:57, 30 March 2014

2014-03-30T15:57:02Z

← Older revision		Revision as of 15:57, 30 March 2014
Line 4:		Line 4:
	* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470995		* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470995
	* http://www.debian.org/vote/		* http://www.debian.org/vote/
	* ProposedSolutionForTheCommunityPoll		* [[ProposedSolutionForTheCommunityPoll]]

AudioGuy at 15:56, 30 March 2014

2014-03-30T15:56:33Z

← Older revision		Revision as of 15:56, 30 March 2014
Line 4:		Line 4:
	* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470995		* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470995
	* http://www.debian.org/vote/		* http://www.debian.org/vote/
			* ProposedSolutionForTheCommunityPoll


	== Notes on the various polls of concern ==		== Notes on the various polls of concern ==

50.45.172.72 at 18:53, 25 March 2014

2014-03-25T18:53:12Z

← Older revision		Revision as of 18:53, 25 March 2014
Line 70:		Line 70:

	== possible solution to the auth problem ==		== 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.		Use md5sum of customer information like name, userid, other stuff that does not normally change.
Line 79:		Line 97:
	that it would be hard for someone to send in fake votes by guessing at valid id numbers.		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 ~~vote~~ would have a uniq number, only used once, but verifiable.		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.		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.		Simple, and requires no real crypto.

50.45.172.72 at 18:43, 25 March 2014

2014-03-25T18:43:29Z

← Older revision		Revision as of 18:43, 25 March 2014
Line 68:		Line 68:

	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. ;-)		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 ==

			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 vote 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.

AudioGuy at 17:45, 25 March 2014

2014-03-25T17:45:09Z

← Older revision		Revision as of 17:45, 25 March 2014
Line 46:		Line 46:
	== Quick look at Devotee ==		== Quick look at Devotee ==

	This is just some ~~wuick~~ first impressions, could be wrong. Want to have NC take a look at this as I think he has some direct experience with it.		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 ===		=== Plusses ===
Line 63:		Line 63:
	* 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 ;-)		* 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		* seems very specifially designed for the Debian system of developers, who have clear access privileges
	* ldap - not sure we want thousands of ~~peole~~ in our ~~lday~~ database with their fequent changes, and if a separate ldap was used, would be a duplication of the slash database in many ways		* 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		* 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 in my remote server)		* 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, caused me to laugh at one point. There really aren't that many ways to do simple voting. ;-)		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. ;-)

AudioGuy at 17:37, 25 March 2014

2014-03-25T17:37:26Z

← Older revision		Revision as of 17:37, 25 March 2014
Line 43:		Line 43:
	* 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 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		* Need a way to insure we have clear title to the name selected

			== Quick look at Devotee ==

			This is just some wuick first impressions, could be wrong. Want to have NC take a look at this as I think he has some direct experience with it.

			=== 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 peole in our lday 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 in my remote server)

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