zigdon has asked for the wisdom of the Perl Monks concerning the following question:

Dear monks,

This might be a slightly off-topic question, but I would like to implement this in perl, if possible. I'm involved with an online-only organization, that is trying to formalize itself - elect officials, define members, etc. And we ran into a problem:

How can you make sure that members that sign up for voting are unique? That a single person wouldn't be able to sign up multiple times, and therefor vote multiple times? Requireing a unique email address is obviously not the answer, considering how easy those are to come by.

So far, the only way we could think of is have a system that will mail you a postcard to a snail-mail address, with a unique code. But I was wondering if there's a better/easier/faster/cooler way of doing this?

Ideas?

-- zigdon

  • Comment on (z) Insuring Uniqueness on the Internet

Replies are listed 'Best First'.
Re: (z) Insuring Uniqueness on the Internet
by dragonchild (Archbishop) on May 01, 2003 at 17:29 UTC
    At some level, there needs to be trust in your community about the identity of the members. There is (currently) no truly perfect way to uniquely identify someone, even in IRL. There are good ones, like fingerprints, DNA, infra-red, retinal, voiceprint, face-matching ... but they can all be fooled. Online, we don't even have the capability of simply counting heads, so trust is even more important.

    The best way I've ever seen for basic authentication is the one used here on PM - username/password. I mean, that's all PayPal uses, at the heart of their authentication system. The thing is that PayPal makes it desirable for someone to only have one account (usually).

    If you're dealing with voting privileges, a good system is to give votes based on seniority, activity, or other criteria. On PM, it's based on XP (which is a very rough judge of activity and fitness, but it is a judge of those things). Now, remember, you don't have to restrict yourself to "One person, one vote". In fact, voting systems that do so are inherently flawed once you have more than two voters and more than two candidates. (I did my undergraduate Math thesis on the topic.) If you allow for "preference voting", things become very easy. (I want 4 votes to go to X, 1 votes to Y, and 0 votes to Z. Or, I want X 1st, Y 2nd, and Z 3rd. Either works.)

    Now, how do these dovetail? Well, you give certain members more votes or more preferences. For example, a newbie gets 0 votes/preferences. Someone who's been active on the system (for some value of active) for some period gets 1 vote/preference, and so forth.

    Yes, this means that those who are more active get more of a say in the community's affairs. However, isn't that just a more honest way of describing the standard political system? Also, isn't that fair? Those members invest more in the community, so they should be rewarded with more clout.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

      This is an interesting idea - basicly saying don't worry about duplicates, since they won't all be really active in the community - there's no gain in that. Need to think how to define "active in the community", but there are some possibilities.

      Cool idea, thanks!

      -- zigdon

        Going further, you can also say "You must be XYZ active to be electable to ABC position." The US has this criteria in that a senator must be 30 years old and a resident of the state for such'n'such time, etc. That is a perfectly valid criteria and those who would complain are those who wouldn't be good members anyways.

        ------
        We are the carpenters and bricklayers of the Information Age.

        Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

        Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Re: (z) Insuring Uniqueness on the Internet
by jonnyfolk (Vicar) on May 01, 2003 at 17:32 UTC
    Presumably you have a membership list. Can you not issue each member an identity number/sequence (eg by email) and catalogue that alongside the membership number.

    When a member votes, verify them with the sequence then simply delete them from the db and that should do it.

    Unless I'm missing something?

      The membership list is what I'm trying to insure the uniqueness in. In this org, anyone can sign up as a member online. So how do I know if joe123 is actually a different person than jake321? That's the problem I'm trying to solve.

      -- zigdon

Re: (z) Insuring Uniqueness on the Internet
by crenz (Priest) on May 01, 2003 at 21:59 UTC

    Unfortunately, anyone can just get another internet account, a new username and password etc. I think you can only get a reasonable accurate authentication with a "real life" mechanism.

    Here in Germany, there's actually a mechanism that allows you to go to any post office. They will authenticate you when you show them your identity card or passport. A few years ago a CA used this to hand out signed PGP keys. Maybe there's something similar available where you live -- it could take some administrative strain from you.

    Another possibility would be to build an infrastructure somewhat like PGP/GPG: Members of the organisation vouch for a new member's identity. Still, for added security you'd still want the new member meet someone in "real life" to be authenticated. Every member would then receive a unique key and send out their votes signed, using their key. You can then ensure everybody only votes once if you can ensure every member can only receive one key. There's a couple other things to consider to set up a good public-key-infrastructure, this is just to get you going.

      A real life mechanism is the only thing we could think of too. Send a postcard to supplied snail-mail addresses, and require a code on that postcard. And while it is possible to get multiple snail mail addresses, it requires a lot more effort that email addresses.

      As for the web-of-trust, I'm not sure how it would work? If I am a member (because someone knows me, say), how do you know that members that put me as their referrer are real people, and not me?

      Just having me saying that "yah, I've met Joe", doesn't prove to anyone that I'm not lying, and I'm really Joe.

      -- zigdon

Re: Insuring Uniqueness on the Internet
by Abigail-II (Bishop) on May 01, 2003 at 22:44 UTC
    How can you make sure that members that sign up for voting are unique?

    I suggest using the same strategy you used to make sure the people you can elect are unique. You solved that, didn't you? If not, then why care whether people can spend more than one vote? Of course, I am assuming that with online-only, you do mean, online only.

    Abigail

      Sorry, but who can be elected is a subset of who's a member. Since only members can be elected to anything, once we solve the unique membership problem, the election uniqueness is not an issue anymore.

      -- zigdon