[EM] Re: touch screen voting machines

Dave Ketchum davek at clarityconnect.com
Sun Nov 16 16:24:03 PST 2003


On Sun, 16 Nov 2003 21:23:07 +0100 David GLAUDE wrote:

> Ken Johnson wrote:
> 
>>> To deal with this, in Belgium by law, if the printed vote is not what 
>>> you like, you call the president of the voting burreau and you vote 
>>> again in front of him. And sorry for the secrecy of your vote. He 
>>> will click on "OK vote match" for you. ;-)
>>>
>> Another possible approach - The voting machine should query the user 
>> to verify that the displayed and printed results are correct, and 
>> press "Accept" BEFORE the result is posted. If the user rejects the 
>> vote, the machine gives them a cancellation receipt as evidence that 
>> their vote has not yet been entered in the system.
> 
> 
> This is exactly what we do.
> The ticket is printed.
> The user is prompted to verify if the printed vote and the on-screen 
> vote are the same. [Please take note that what is on screen might be 
> different from the voter intent. Let say I click A and the computer 
> display B and print B!!! How do I complain?]

If it displays B AND prints B, you have ZERO cause for complaint - the 
printing is EXACTLY CORRECT.

Stepping back, if you intended to click A and managed to get B, THAT 
is the time to consider:
     Likely your finger slipped - time to go back and correct your 
clicking.
     The machine is broken, so get this attended to.  If there is 
refusal to respond to demonstration that machine is broken, time to 
declare war.

BTW - the machine - hardware and software - should have been open 
source, so we should not be in this path without an unlikely failure 
of this sort.
     
Setup of the ballot definition looks like an easier path to failure here.
Could be design makes it too easy to make mistakes here.  Could be 
carelessness in setup.
          
> * If you accept, the ticket is "CUT" and fall inside the ballot box 
> (this mean there is a printer and ballot box attach to each voting 
> machine). The voter can only see one vote (the last one, his own vote) 
> and has no physical access to the ticket/printer/ballot box.

Agreed.

> * If you do not accept, then a CANCEL LINE is printed on the ticket 
> (paper) as to remind that this paper ballot should not be counted during 
> the manual recount. But there come the president of the voting place. 
> Some kind of an alarm ring and he get to help you vote and verify the 
> behaviour of the machine. This is where you loose the secrecy of your 
> vote...

I am back to broken machine or careless voter.  Certainly no reasonable 
provision for getting that printed ballot near a printer.
     BUT - inspector could be given a way to tell the machine to print a 
second copy of the ballot, with this copy canceling the first copy.
> 
> I don't know how practicaly it take place because this was experimented 
> on two location only. I only have the law (and source code) to read in 
> order to understand what are the possible scenario.
> 
> But we have too many vote representation to deal with:
> * Voter intent
> * On screen vote
> * On paper vote (our ticket)
> * On the magnetic card vote
> * Vote as readed by ballot box
> * Vote as counted at the end of the day
> * Vote as counted on the ticket at the end of the day
> 
> Making sure all those match and will match is difficult.

Most of this is simply seeing to proper design such as making it easy 
for voter to express intent and minimizing chance of machine failure.
> 
>>> Partial recount are useless... How do you know the computer was not 
>>> just showing what you wanted to see?
>>
>>
>> The computer doesn't need to know what you want to see. Rather than 
>> querying the computer to validate a specific vote, you just download 
>> the entire vote database, sorted by vote serialization ID, and inspect 
>> it directly.
> 
WRONG - secrecy PROHIBITS attaching an identifying ID to the recorded ballot.
> 
> Should I stress one more time to PRINT the database and then verify 
> whatever you want to verify.

The printing is doable - and if it SAYS NO ONE voted as you SAY YOU DID, 
then we have finger pointing to sort out.
> 
>>> 1.  MUST enable potential recounts
>>>
>> Why is that a necessity? If the election result is invalidated, just 
>> hold another election. Computerization, combined with robust 
> 
> 
> The point is that in most election we want all the citizen of the state 
> to vote at the same time without influance of the result of other 
> location. That's why in my country and other european country, no poll 
> result can be given in the few days bevore the vote and until all had a 
> chance to vote.

Your topic makes sense, except I do not see it fitting here.
> 
> It would be easy to influance the vote by announcing some partial result 
> before the end. (Remember Florida). So

Ditto.
> 
>> verification means, should make voting processes and software as 
>> efficient and reliable as commercial financial systems, 
> 
Certainly we NEED more attention to quality than seems to be happening in 
the US.

Fact that "commercial financial systems" are acceptably "efficient and 
reliable" makes it clear that our first need is to get vendors interested 
in doing likewise before they propose getting involved in voting machines.
> 
> I would prefere no software, if software there is then I don't care 
> about efficiency, but I want reliability of software for spaceship and 
> nuclear power station. All written in very secure language like ADA and 
> with pre- and post- condition raising exception is parameter or result 
> are outside of scope or do not pass some sanity test... I want the code 
> to be free software or open source for peer review...
> 
Agreed that efficiency in processing time is of little interest for
the required processing is simple.

Efficiency in program design is IMPORTANT, for design can be made so 
stupidly complex as to be impossible to validate.

I was around when Ada (the language) was born and, unless it has 
improved A LOT, better if it had died YOUNG.  I would have more hope for 
Java or Linux.

"Open source" is something we can agree on and EMPHASIZE.

>  > so this should be an exceptionally rare occurence.
> 
> Believe me, shit happen. In 12 years of electronic election in Belgium, 
> there was no single election without technical problem... be it hardware 
> or software.
> 
> Confidence in the result and user acceptance of electronic voting 
> decrease each time. ;-)
> 
> David GLAUDE

-- 
  davek at clarityconnect.com    people.clarityconnect.com/webpages3/davek
  Dave Ketchum   108 Halstead Ave, Owego, NY  13827-1708   607-687-5026
            Do to no one what you would not want done to you.
                  If you want peace, work for justice.




More information about the Election-Methods mailing list