Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Voting Project Needs Python People

Reply
Thread Tools

Voting Project Needs Python People

 
 
Alan Dechert
Guest
Posts: n/a
 
      07-22-2003
"Paul Rubin" <http://(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Alan Dechert" <(E-Mail Removed)> writes:
> > > 1. Software chooses 1% of votes to change (big enough to have an
> > > effect, small enough to maybe go unnoticed).
> > >

> > I don't think this is a possible scenario. However, it brings up an
> > interesting test for our full blown study (keep in mind, we're trying to
> > focus on getting the demo done even though people want to jump ahead to
> > speculate on every possible detail).

>
> But something like that seems to have happened in Escambia County,
> Florida, in 2000. Out of 21,500 absentee ballots cast, 296 (1.5% of
> the total) were overvotes with three or more presidential candidates
> checked. ZERO were overvotes with exactly two candidates checked.
> Ballot tampering after the ballots were received is the most plausible
> explanation.
>

But that's a different scenario. As you described it, the voter never had a
chance to see the alteration. The scenario Harry described is where the
voter has the altered ballot in hand but doesn't notice.

> You said that in your system the paper ballots are
> supposed to take priority over the electronic count if there is a
> dispute (that's the whole point of having the paper ballots). So it
> doesn't matter if the paper and electronic results don't match, and
> the tampering doesn't have to happen while the voter can still see the
> ballot.
>

I don't see much of a point here. It will be very hard -- if not
impossible -- to tamper with the printout in a manner that would go
undetected. First of all, overvotes will not be possible at all. I can't
quite visualize how you figure someone will alter the printout. Take some
whiteout and cover one name and print in a new one? That would look pretty
obvious. Furthermore, the bar code would no longer match the text. In my
scheme, the tamperer would have no way to know how to alter the bar code to
match any alterations in the text.

Post election checks (canvass period) would involve hand checks, and scanner
checks of the bar code and the text. It all has to match.

> Reference:
>
> http://www.failureisimpossible.com/essays/escambia.htm
>
> Note: Paul Lukasiak, the main author of that article, did some of the
> most thorough analysis of the Florida debacle that I've seen. I hope
> you will read a lot of his stuff in designing your real system, so
> you'll be able to say how your system deals with the problems that he
> identified in Florida.
>

I read as much as possible and will continue to study all of this. Keep in
mind that some of the people on our team are leading experts in the field.
They know all this stuff inside out. We'll bring in more experts once the
study is funded.

Nobody is saying this issue is simple. Almost everyone that has approached
the voting mess dilemma and tried to figure it out has grossly
underestimated the problem. I have to say I underestimated too but I have
stuck with it long enough and hard enough to get a handle on it. Our
Election Rules Database (the largest component of our proposed study) will
surface inordinate problems -- get them out in the open where we can deal
with them.

Alan Dechert






 
Reply With Quote
 
 
 
 
Matt Shomphe
Guest
Posts: n/a
 
      07-22-2003
"Alan Dechert" <(E-Mail Removed)> wrote in message news:<LDVSa.14955$(E-Mail Removed) rthlink.net>...

> We have an excellent team together. We're looking for a few good Python
> coders willing to volunteer for this free open source project. It will be
> on sourceforge.net later today.


Are there any prerequisites for joining the team?
 
Reply With Quote
 
 
 
 
Alan Dechert
Guest
Posts: n/a
 
      07-22-2003
"Matt Shomphe" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> "Alan Dechert" <(E-Mail Removed)> wrote in message

news:<LDVSa.14955$(E-Mail Removed) rthlink.net>...
>
> > We have an excellent team together. We're looking for a few good Python
> > coders willing to volunteer for this free open source project. It will

be
> > on sourceforge.net later today.

>
> Are there any prerequisites for joining the team?
>

It would be nice if you know some Python. Do you?

BTW, I'm told it will take a day or two to get the project going on
sourceforge.net.

Alan Dechert


 
Reply With Quote
 
Harry George
Guest
Posts: n/a
 
      07-22-2003
"Alan Dechert" <(E-Mail Removed)> writes:

> "Paul Rubin" <http://(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > "Alan Dechert" <(E-Mail Removed)> writes:
> > > > 1. Software chooses 1% of votes to change (big enough to have an
> > > > effect, small enough to maybe go unnoticed).
> > > >
> > > I don't think this is a possible scenario. However, it brings up an
> > > interesting test for our full blown study (keep in mind, we're trying to
> > > focus on getting the demo done even though people want to jump ahead to
> > > speculate on every possible detail).

> >
> > But something like that seems to have happened in Escambia County,
> > Florida, in 2000. Out of 21,500 absentee ballots cast, 296 (1.5% of
> > the total) were overvotes with three or more presidential candidates
> > checked. ZERO were overvotes with exactly two candidates checked.
> > Ballot tampering after the ballots were received is the most plausible
> > explanation.
> >

> But that's a different scenario. As you described it, the voter never had a
> chance to see the alteration. The scenario Harry described is where the
> voter has the altered ballot in hand but doesn't notice.
>


No, I said the paper and the CRT or LCD were correct. It was just the
electronic storage that was altered.


> > You said that in your system the paper ballots are
> > supposed to take priority over the electronic count if there is a
> > dispute (that's the whole point of having the paper ballots). So it
> > doesn't matter if the paper and electronic results don't match, and
> > the tampering doesn't have to happen while the voter can still see the
> > ballot.
> >

> I don't see much of a point here. It will be very hard -- if not
> impossible -- to tamper with the printout in a manner that would go
> undetected. First of all, overvotes will not be possible at all. I can't
> quite visualize how you figure someone will alter the printout. Take some
> whiteout and cover one name and print in a new one? That would look pretty
> obvious. Furthermore, the bar code would no longer match the text. In my
> scheme, the tamperer would have no way to know how to alter the bar code to
> match any alterations in the text.
>
> Post election checks (canvass period) would involve hand checks, and scanner
> checks of the bar code and the text. It all has to match.
>
> > Reference:
> >
> > http://www.failureisimpossible.com/essays/escambia.htm
> >
> > Note: Paul Lukasiak, the main author of that article, did some of the
> > most thorough analysis of the Florida debacle that I've seen. I hope
> > you will read a lot of his stuff in designing your real system, so
> > you'll be able to say how your system deals with the problems that he
> > identified in Florida.
> >

> I read as much as possible and will continue to study all of this. Keep in
> mind that some of the people on our team are leading experts in the field.
> They know all this stuff inside out. We'll bring in more experts once the
> study is funded.
>
> Nobody is saying this issue is simple. Almost everyone that has approached
> the voting mess dilemma and tried to figure it out has grossly
> underestimated the problem. I have to say I underestimated too but I have
> stuck with it long enough and hard enough to get a handle on it. Our
> Election Rules Database (the largest component of our proposed study) will
> surface inordinate problems -- get them out in the open where we can deal
> with them.
>
> Alan Dechert
>
>
>
>
>
>


--
http://www.velocityreviews.com/forums/(E-Mail Removed)
6-6M31 Knowledge Management
Phone: (425) 294-8757
 
Reply With Quote
 
Alan Dechert
Guest
Posts: n/a
 
      07-22-2003

"Harry George" <(E-Mail Removed)> wrote in message
news(E-Mail Removed)...
>
> No, I said the paper and the CRT or LCD were correct. It was just the
> electronic storage that was altered.
>

Okay, right. My mistake. I read #1 as one scenario and #2 as different
scenario.

Nonetheless, I maintain that such a game would be caught easily. Checking a
very small sample before announcing the preliminary (electronic) count would
catch it. If one percent of the electronic votes were altered (evenly
distributed), you will find one mismatch for sure after checking only a
dozen or two ballots. If the one percent is not evenly distributed, it will
show up as very suspicious results in the areas where the alterations were
concentrated. So, before announcing the electronic count, the result should
be given a common sense review. For example, if Orange County in CA shows
75 % for the Democrat you know something's wrong (or San Francisco shows 75
% for the Republican). Then samples should be checked in various locations
with any unexpected looking results getting special attention.

If you find one mismatch while sampling, you know there's a problem and the
tally would be delayed until all the paper ballots have been scanned. Then
you do some manual checking of the results from scanning.

Then, you figure out how the rigging was carried out. If the machines were
rigged all over, this would imply a very large conspiracy -- a very large
risk for a large number of people doing something that will be caught with
absolute certainty (thus very unlikely to happen).

Alan Dechert



 
Reply With Quote
 
Alan Dechert
Guest
Posts: n/a
 
      07-23-2003
"Andrew Dalke" <(E-Mail Removed)> wrote in message
news:bfkch9$is4$(E-Mail Removed)...
> Alan Dechert:
> > catch it. If one percent of the electronic votes were altered (evenly
> > distributed), you will find one mismatch for sure after checking only a
> > dozen or two ballots.

>
> Actually, around 70 ballots.
>
> The odds of finding one ballot to be wrong is 1%, so there's a 99%
> chance that it's unaltered. There's a 0.99*0.99 chance that two are
> unaltered, and in general a 0.99**n chance that n are unaltered.
>
> To get even odds of noticing an error requires
>
> 0.99**n == 0.5
> --> log(0.99)*n == log(0.5)
>
> >>> math.log(0.5) / math.log(0.99)

> 68.967563936528421
> >>>

>
> about 70 verifications.
>

A likely story. I actually took combinatorics and a class in statistics in
college. But that was a long time ago. Since then, many brain cells have
died, tragically.

BTW, do you know about cumulative binomial distribution? I think we need to
include a tool like this to give us some "C.L" (confidence level) short of
verifying that every single paper ballot matches its electronic counterpart.

http://www.reliasoft.com/newsletter/...e_binomial.htm

What I really want is a calculator. Do you know of a free calculator for
this? If not, could you make one? (for free, of course).

Alan Dechert


 
Reply With Quote
 
Andrew Dalke
Guest
Posts: n/a
 
      07-24-2003
Alan Dechert:
> BTW, do you know about cumulative binomial distribution? I think we need

to
> include a tool like this to give us some "C.L" (confidence level) short of
> verifying that every single paper ballot matches its electronic

counterpart.
>
> http://www.reliasoft.com/newsletter/...e_binomial.htm
>
> What I really want is a calculator. Do you know of a free calculator for
> this? If not, could you make one? (for free, of course).


I don't know anything about it, although looking at it I think I understand
what it's trying to do. Here's the equation for those following along

r
1 - C.L. = Sum C(N, k) * (1-R)**k * R**(N-k)
k=0

where R(N, k) = N! / (k! * (N-k)!)

and C.L. is the confidence level,
N is the number of votes tested
r is the maximum allowable number of errors, and
R is the reliability (scanning errors, attempts at voting fraud, etc.)

The problem is, I don't see how to use it. Here's the case I
had in mind. Suppose you have 100,000 votes and want to
be 90% certain that there is no more than 1% error. This means
you'll need to retest N ballots (the ballots "under test"). Then
the variables are:

C.L. = 0.90
N = to be determined
r = N * 0.01
R = ???

and I just don't know what to use for R. Let's say it's <0.1%. Then

N*0.01
1 - 0.9 = Sum C(100000, k) * (1-0.001)**k * (0.001) ** (N-k)
k=0

and solve for N.

I wouldn't want to write a calculator for it without the verification of
someone who knows it better than I do. The only way I know to
solve this iteratively, and given the large and small numbers involved,
I would worry about numerical problems like overflow and underflow.
(OTOH, for those cases, approximations like the Stirling expansion
for factorials come into play. But my math for this is entirely too
rusty.)

So no, I can't help you further than this.

BTW, I don't think you need to distribute a calculator for this. I think
you just need some tables which give values for a few select points,
as in:

# | 75% certain | 90% | 98% || 90% | 98%
ballots | of no more than | .. | || |
| 1% error rate | 1% | 1% || 5% | 5%
------------------------------------------------------------
100 | values ....
200 | values ....
....


Andrew
(E-Mail Removed)


 
Reply With Quote
 
Paul Rubin
Guest
Posts: n/a
 
      07-25-2003
"Alan Dechert" <(E-Mail Removed)> writes:
> BTW, do you know about cumulative binomial distribution? I think we need to
> include a tool like this to give us some "C.L" (confidence level) short of
> verifying that every single paper ballot matches its electronic counterpart.


I'm skeptical of that approach. It assumes independent events. You
should probably talk to a real statistician. This is the kind of
stuff they do all the time.
 
Reply With Quote
 
Alan Dechert
Guest
Posts: n/a
 
      07-27-2003
"Andrew Dalke" <(E-Mail Removed)> wrote in message
news:bfo1k3$n2s$(E-Mail Removed)...

> BTW, I don't think you need to distribute a calculator for this. I think
> you just need some tables which give values for a few select points,
> as in:
>

I still want a calculator. Here's what Bill Buck ( (E-Mail Removed) ) sent
me. It turns out there is a BINOMDIST function in Excel. I think it might
be what I want.

http://home.earthlink.net/~adechert/...Calculator.xls

Let me try to clarify what I'm after. The paper record should always match
the electronic record. So the allowable defects is zero. If there is a
mismatch found in the sample, we don't publish the electronic tally: we take
all the paper ballots and check them.

We are talking about an election conducted with computer-generated paper
ballots. The paper ballots represent the actual vote since these ballots
are what voters actually saw, verified, and cast. We will have an
electronic record obtained from the computers which should match each paper
ballot generated. We want to use the electronic record since it will give
us an instant result -- but we have to check it against the paper ballots to
be sure the election result is correct. So, in this scenario, the
electronic count is a prediction (or preliminary tally).

So, if by the preliminary electronic tally a candidate won a race by 1
percent, I want to know how many ballots we have to check (random sample) to
be certain that the result predicted is true.

When I put one million into this Confidence Level Calculator, and Acceptable
Quality Level of .01, a sample of 10,000 shows a confidence level of "1." A
sample of 2000 give C.L of 0.999999998 Presumably, "1" is really
..9999999999+ more 9s. Can we get more decimal places?

So I guess the Lot Fraction Defective is analgous to the predicted victory
margin. Is that right?

I would still like a standalone calculator that doesn't require Excel.

Alan Dechert


 
Reply With Quote
 
Alan Dechert
Guest
Posts: n/a
 
      07-27-2003
"Ian Smith" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...


> There's a lot of assumed knowledge in this discussion. I know nothing
> about electronic voting systems, I know almost nothing about Python as
> a programming language but I do know how to calculate values
> associated with the cumulative binomial distribution. A Javascript
> (sorry!) calculator for the binomial distribution amongst others can
> be found at http://members.aol.com/iandjmsmith/EXAMPLES.HTM.
> Javascript can be converted to Java, C etc quite easily. I would
> imagine with my lack of knowledge of Python you'll probably be better
> off doing the conversion yourself.
>
> The code is quick and accurate and can handle large sample sizes and
> very small probabilities which you probably need. There's even a
> calculator for the Hypergeometric distribution should you wish to do
> sampling without replacement calculations.
>
>
> Ian Smith
>
> P.S. the calculation of 70 is fine. If you don't want to calculate
> anything much more difficult then you probably don't need a calculator
> anyway.
>

Thanks, Ian. I could not quite figure out if your binomial distribution
calculator would be applicable.

Here's what Bill Buck ( (E-Mail Removed) ) sent me. It turns out there is a
BINOMDIST function in Excel. I think it might be what I want.

http://home.earthlink.net/~adechert/...Calculator.xls

Let me try to clarify what I'm after. The paper record should always match
the electronic record. So the allowable defects is zero. If there is a
mismatch found in the sample, we don't publish the electronic tally: we take
all the paper ballots and check them.

We are talking about an election conducted with computer-generated paper
ballots. The paper ballots represent the actual vote since these ballots
are what voters actually saw, verified, and cast. We will have an
electronic record obtained from the computers which should match each paper
ballot generated. We want to use the electronic record since it will give
us an instant result -- but we have to check it against the paper ballots to
be sure the election result is correct. So, in this scenario, the
electronic count is a prediction (or preliminary tally).

So, if by the preliminary electronic tally a candidate won a race by 1
percent, I want to know how many ballots we have to check (random sample) to
be certain that the result predicted is true.

When I put one million into this Confidence Level Calculator, and Acceptable
Quality Level of .01, a sample of 10,000 shows a confidence level of "1." A
sample of 2000 give C.L of 0.999999998 Presumably, "1" is really
..9999999999+ more 9s. Can we get more decimal places?

So I guess the Lot Fraction Defective is analgous to the predicted victory
margin. Is that right?

I would still like a standalone calculator that doesn't require Excel.

Alan Dechert


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Volunteer -- Java/XML for Open Source Public Voting Project dechert@gmail.com Java 4 07-02-2007 04:58 PM
Perl Programmers, America Needs Your Help! We Need Secure Voting Machines Dave Roberts Perl Misc 24 01-23-2004 05:59 PM
MORE volunteers for voting project needed Alan Dechert Python 0 09-16-2003 10:58 PM
Python - PC based Voting Machine Project Announcement Alan Dechert Python 0 08-08-2003 03:35 PM
Possible use of Python for a voting machine demo project -- your feedback requested Alan Dechert Python 29 07-23-2003 02:04 AM



Advertisments