[ga] Registration process

[david@aminal.com]

This problem is reduced by making the registration list a list of
people's *names*, along with some identifying information,
not a list of email addresses. Anonymous participation in lists
can be maintained by not making the associated email addresses of
the registered voters public along with their names. This info
would only be used to communicate with the voter during registration
and polling.

Once you have a name, it is much easier to determine if a person
is real and unique. 

The idea of making the registration roles public is to allow those
who wish to question or verify the existence of a person on the
list the opportunity to do so. It should be the responsibilty of
the electorate themselves to police the roles. 

Secure communciations between the voting system and the electorate
is a different question, and the easiest solution is public ballots,
so that everyone can be sure that their vote was recorded as they
intended, with everyone verifying from the same list.

Secret ballots would need secure communications channels between
the voters and the election system, and a great deal of trust in
those compiling the results of the election.

Neither of these conditions is likely to be satisfied soon.

Start simple, implement a lightweight (though less than ideal)
system, and carefully watch for problems. As experience is gained,
the level of trust in the system will increase.

Trying to put together a robust system with ideal features using
purely technical means will only increase barriers to participation.

Not to mention the cost. 

David Schutt
david@aminal.com

 
On Thu, Feb 03, 2000 at 06:52:35PM -0800, Roeland M.J. Meyer wrote:
> There are two problems extant.
> 1) Aliasing and masquerading, usurping someone else's email identity.
> 2) Multiple identities for the same individual.
> 
> The first one is easily automatable.
> 
> a) Voter registration system has PK set
> b) Voter registration system *is* a voter CA.
> 
> 1) Voter generates/obtains x.509 key set (see your local CA)
> 2) Voter submits registration form along with public key and CRL.
> 3) System return, via email, voter CA certificate.
> 
> All further email, both ways must be signed, after this point, including ALL
> discussion list submissions. Those not signed or failing certification do
> not get posted.
> 
> The second one is more difficult. There is no way that I can see, where we
> can automate this. A human MUST be involved in the registration process to
> investigate any possible duplicates. It is altogether too easy, for those of
> us whom are our own ISP, to generate multiple identities. Also, there are
> those who use AOL, Hotmail, Juno, and other free email accounts, often
> multiple times. Not to mention the separate business and personal email
> identities that almost all of us HAVE to have, in order to abide by
> corporate mail usage policies.
> 
> A naive system would simply ask for all known email addresses at the time of
> registration and have some sort of updating mechanism. However, there is
> that dishonorable 1% that would abuse such a naive system, simply because
> they can. We already have clear examples of that.
> 
> A bright note here is that I just finished dealing with this problem on a
> user profiling system for a LARGE web-site, using BroadVision's profiling
> mechanism, under Solaris v2.6. It is not a 100% solution, but it covers a
> lot of the required ground. The problem is that a BV license is >$100K. If
> you don't think that marketing orgs worry about multiple entries in their
> demographics data, you are wrong.
> 
>