[EM] Why We Shouldn't Count Votes with Machines

[rob brown]

On Tue, Aug 12, 2008 at 9:01 PM, Kathy Dopp <kathy.dopp at gmail.com> wrote:

> > Message: 2
> > Date: Tue, 12 Aug 2008 18:17:49 -0700
> > From: "rob brown" <rob at karmatics.com>
> > Subject: Re: [EM] Why We Shouldn't Count Votes with Machines
> > The "two strikes you are out" rule is not inherent to machine voting --
> that
> > is fixable, obviously.
>
> How?  Do we want an infinite loop of a voter running paper through a
> cheap printer trying to obtain an accurate ballot record and the
> machine refusing to print one while it switches a vote wrongly?  Or do
> we want the voter to be able to cancel the ballot and let the poll
> workers know that he needs a paper ballot instead that he can mark
> himself?


I'm fine with the latter.  Actually that seems like a reasonable thing to
do.


>  If so, why not let the voters vote on a paper ballot to
> begin with?
>
> Any ideas?


Cost?

Presumably they don't use the paper ballot to begin with because then they
have to be hand counted or have an optical reader at each station.  Hand
counting a few is reasonable (or sending them in to be counted on an optical
reader),  hand counting all, or having modern optical machines at each
polling station, can be very expensive.

But honestly, the big problem I have with paper ballots filled out by hand
is that they make the transition to a ranked system a lot harder, both in
terms of difficulty filling in the ballot and difficulty counting them.  As
you probably know, I am a big advocate of ranked systems (especially
condorcet), as plurality is (among other sins) the source of partisanship
which I consider the biggest problem of government.

> Regardless, are you suggesting that a programmer could steal an election
> by
> > just hoping that that every one of the people who had it fail twice in a
> row
> > is going to simply say "oh well" and go home, rather than raise holy hell
> > about it?
>
> No. Obviously it is trivially easy for any programmer of a voting machine
> to:
>

You'll note that I said it is essential that the source code be open for
viewing by all.  Not so trivially easy in that case.  Not at all.


> a. make the printed ballot record match an erroneous e-ballot record
> on the voters first try
>
> b. in the 10% of cases when a voter notices the error on the paper
> ballot and cancels the ballot, the programmer than makes the paper
> printout and the electronic record match exactly what the voter wants.
>

But to do this, an awful lot of people are going to see the error,
especially if you simply leave it on screen when you print the paper copy.
And they are going to talk about it.  And the next year, people will be a
lot more likely to notice.

Still, with an open source system, I have no clue how a programmer is going
to do this at all.  If there is someone that smart (and lacking of ethics),
he is probably very, very rich, as he probably has already put undetected
code in the linux kernel that is giving him back doors to an awful lot of
servers out there moving an awful lot of money.

Most likely though, no one is able to hide such devious stuff in code
visible to security researchers.


> Recall that I said that the programmer would only be able to switch up
> to 90% of the target votes without any audit able to detect it.
>

Only if every single voter got a wrong ballot printed.  You really think
this would go unnoticed?   Your scenario is absurd, at least on the scale
you talk about.

The voter would either think that he must have made a mistake on the
> first try, or complain about his vote being switched.
>

Yes, and a lot of people complaining would draw more attention to it, and
more people would start checking.  If it happened on a large scale, the
problem would be tracked down,  and the programmer would be put away for a
long time.

But if it is open source, even that scenario is (for all intents and
purposes) impossible.


> We have already seen hundreds or thousands or cases of voters in the
> last two election cycles complaining that their votes have been
> switched to the wrong candidates with DREs and election officials have
> mostly ignored the problem or chalked it up to "touchscreen
> callibration" problems (which does cause similar behavior)
>

Not if the UI is done reasonably.  The touch screen should show what you
selected, very clearly, in big bold letters so you know you did it right,
and allow you the opportunity to change it before printing out the paper.
If it then prints out a different thing, that is obviously not "touchscreen
calibration", and if it does it for a significant number of people that
isn't going to last long before you have the townspeople carrying torches.


> > As a programmer myself, I can tell you that any non-stupid (but evil)
> > programmer would have it do it correctly the second time....I mean, you
> know
> > they are looking that time, so why push your luck for one vote?  So the
> "2
> > strikes and you're out", silly as it may be, is hardly the issue.
>
> Huh?
>
> I mentioned TWO SEPARATE ISSUES:
>

Ok, well you complained loudly about the two strikes then you're out rule,
which doesn't seem relevant or at least doesn't seem to be a necessity.  It
could just be eliminated, and let you do it until you get it right.  I know,
that doesn't solve the problem for people who don't check their ballots, but
still...


> 1. the programming hack that can switch 90% of target votes without
> audits being able to detect it.
>
> 2. the 2 strikes you're out rule that *all* DREs currently use today
> that prevents even the 10% of diligent voters who detect errors in
> their paper printed records from being able to generate a correct
> machine-printed paper ballot record.
>
> If you prefer not have *any* paper ballot record, then ofcourse there
> is no way to check the accuracy of the machine counts independent of
> the programming.


For the record, I absolutely do prefer a paper ballot record.  Along with
open source.


> > I can also tell you that much of the issue here is far out of the field
> of
> > computer science, and is more in the area of sociology/psychology with a
> > little game theory and economics thrown in.
>
> Really?


Yes, certainly the aspect of whether humans will notice that large scale
fraud is happening, the media will take an interest, etc, is not a computer
science issue.

 OK, but *all* independent computer scientists (that I know)
> oppose the use of e-ballot voting systems for very solid logically
> correct reasons.


> It is true that e-ballots with machine printed paper records *might*
> work (although still expensive and subject to DOS attacks)


DOS attacks?  Really?  Are you talking about voters coming in and using up
all the paper, or what?  (which is a stretch of the definition of DOS
attack)

*IF* you
> could train all voters and election officials and poll workers
> adequately how to handle doing elections with them, but that seems
> like a very remote possibility unless you want to begin lessons in how
> to use e-ballot paper trail voting systems in grammar school as a
> course and have paper ballots as backup available in every polling
> location and train pollworkers and voters to recognize when the
> machines look like vote fraud may be going on, etc.  Human factors
> must be considered realistically.
>

Well human factors is my profession (degree in industrial design, working
for ~20 years doing UI design / programming).  Seems to me a solvable
problem, and not a particularly hard one.

> I don't disagree that there are problems with machine voting, some easier
to
> fix than others.  (a paper trail is an absolute necessity, for instance,
as
> is open source code)

Again, virtually all *independent* computer scientists who are voting
> system experts disagree with you and believe that voter-marked paper
> ballots are essential and that "paper trails" are inadequate as I've
> tried to explain some of their flaws here.
>

You keep saying that, I'm not convinced.  But as I said, I'm also not
convinced that computer science degrees makes such a difference, as I don't
think most of the issues are computer science issues.

> Still I think you are blowing things out of
> proportion  -- to a large enough degree that your propoganda has pulled me

> > out of my typical lurk mode on the list.
>
> Well using words like "propaganda" and "blowing things out of
> proportion" are very skillful ways to try to discount real facts, but
> do not impress me, or most people as much as concrete facts do.
>

I'm into concrete facts as well, which is why I called you on the Shamos
thing.  I think you are blowing things out of proportion in this discussion
and even more so regarding IRV.


> It still remains true though, that Michael Shamos is considered a
> rogue computer scientist and that Michael Shamos financially profits
> handsomely by certifying DRE voting systems for the state of PA which
> can not be shown to be inaccurate since they are paperless and there
> is no software independent method to audit their output.
>

I don't agree with Shamos at all, for the record.  I think a paper trail is
absolutely necessary.  I just don't think sticking with hand-filled paper
ballots (except as a fallback) is the solution.

(but I would suggest that if you are going to talk smack about someone on a
public list, Google is your friend)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20080812/35bc949c/attachment-0001.htm>