ixd failure(?) exploited for voting fraud

25 Mar 2009 - 8:35am
5 years ago
8 replies
452 reads
jet
2008

The entire article is worth reading (and has actual hot links), but I'll
call out how the design failure(?) was exploited by pollworkers to
change votes:

<http://www.crypto.com/blog/vote_fraud_in_kentucky/>

[...]

The Kentucky officials are accused of taking advantage of a somewhat
confusing aspect of the way the iVotronic interface was implemented.
In particular, the behavior (as described in the indictment)
of the version of the iVotronic used in Clay County
apparently differs a bit from the behavior described in ES&amp;S's standard
<a href="http://www.essvote.com/HTML/docs/iVotronic.pdf">instruction sheet
for voters [pdf - see page 2]</a>.
A <a href="http://www.essvote.com/HTML/iVotronicDemo1/demo.html">flash-based
iVotronic demo available from ES&amp;S here</a> shows the same
procedure, with the VOTE button as the last step. But evidently
there's another version of the iVotronic
interface in which
pressing the VOTE button is only the <em>second to last</em> step. In
those machines, pressing VOTE invokes an extra "confirmation" screen.
The vote is only actually finalized after a "confirm vote" box is touched
on that screen. (A different flash demo that shows this behavior with the
version of the iVotronic equipped with a printer is available from ES&amp;S

<a href="http://www.essvote.com/HTML/iVotronicDemo2/index.html">here</a>).
So the iVotronic VOTE button doesn't necessarily work the way a
voter who read the standard instructions might expect it to.
<p>
The indictment describes a conspiracy to exploit this ambiguity in
the iVotronic user interface by having pollworkers systematically
(and incorrectly) tell voters that pressing
the VOTE button is the last step. When a misled voter would leave the
machine with the extra "confirm vote" screen still displayed, a pollworker
would quietly "correct" the not-yet-finalized ballot before casting it.
It's a pretty elegant attack, exploiting
little more than a poorly designed, ambiguous user interface, printed
instructions that conflict with actual machine behavior, and public
unfamiliarity with equipment that most citizens use at most once or twice
each year. And once done,
it leaves behind little forensic evidence to expose the deed.

[...]

--
J. Eric "jet" Townsend, CMU Master of Tangible Interaction Design '09

design: www.allartburns.org; hacking: www.flatline.net; HF: KG6ZVQ
PGP: 0xD0D8C2E8 AC9B 0A23 C61A 1B4A 27C5 F799 A681 3C11 D0D8 C2E8

Comments

25 Mar 2009 - 8:57am
Dana Chisnell
2008

There are a number of confusing things that happen at the end of the
voting process on an iVotronic. And casting a ballot always takes two
steps on these machines.

1. There are *two* places where a voter can answer the call to action:
a physical button at the top of the screen that lights up red when the
voter reaches the summary/review screen, and a green button in the
touchscreen UI that usually says something like "Cast your ballot."

THEN

2. There's a confirmation screen. But the messaging there isn't always
obvious. Here, the voter touches Cast Ballot again.

What the Kentucky election officials did was tell voters they were
done when they had taken the first step. Then they went back to the
voting booth and hit a Back button to go through the ballot again,
changing votes. Then they cast the ballots themselves.

This article has a pretty good explanation of what happened: http://www.bradblog.com/?p=7001

Dana

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
Dana Chisnell
desk: 415.392.0776
mobile: 415.519.1148

dana AT usabilityworks DOT net

www.usabilityworks.net
http://usabilitytestinghowto.blogspot.com/

On Mar 25, 2009, at 6:35 AM, j.eric townsend wrote:

> The entire article is worth reading (and has actual hot links), but
> I'll
> call out how the design failure(?) was exploited by pollworkers to
> change votes:
>
> <http://www.crypto.com/blog/vote_fraud_in_kentucky/>
>
> [...]
>
> The Kentucky officials are accused of taking advantage of a somewhat
> confusing aspect of the way the iVotronic interface was implemented.
> In particular, the behavior (as described in the indictment)
> of the version of the iVotronic used in Clay County
> apparently differs a bit from the behavior described in ES&amp;S's
> standard
> <a href="http://www.essvote.com/HTML/docs/iVotronic.pdf">instruction
> sheet
> for voters [pdf - see page 2]</a>.
> A <a href="http://www.essvote.com/HTML/iVotronicDemo1/
> demo.html">flash-based
> iVotronic demo available from ES&amp;S here</a> shows the same
> procedure, with the VOTE button as the last step. But evidently
> there's another version of the iVotronic
> interface in which
> pressing the VOTE button is only the <em>second to last</em> step. In
> those machines, pressing VOTE invokes an extra "confirmation" screen.
> The vote is only actually finalized after a "confirm vote" box is
> touched
> on that screen. (A different flash demo that shows this behavior
> with the
> version of the iVotronic equipped with a printer is available from
> ES&amp;S
>
> <a href="http://www.essvote.com/HTML/iVotronicDemo2/
> index.html">here</a>).
> So the iVotronic VOTE button doesn't necessarily work the way a
> voter who read the standard instructions might expect it to.
> <p>
> The indictment describes a conspiracy to exploit this ambiguity in
> the iVotronic user interface by having pollworkers systematically
> (and incorrectly) tell voters that pressing
> the VOTE button is the last step. When a misled voter would leave the
> machine with the extra "confirm vote" screen still displayed, a
> pollworker
> would quietly "correct" the not-yet-finalized ballot before casting
> it.
> It's a pretty elegant attack, exploiting
> little more than a poorly designed, ambiguous user interface, printed
> instructions that conflict with actual machine behavior, and public
> unfamiliarity with equipment that most citizens use at most once or
> twice
> each year. And once done,
> it leaves behind little forensic evidence to expose the deed.
>
> [...]
>
>
>
>
> --
> J. Eric "jet" Townsend, CMU Master of Tangible Interaction Design '09
>
> design: www.allartburns.org; hacking: www.flatline.net; HF: KG6ZVQ
> PGP: 0xD0D8C2E8 AC9B 0A23 C61A 1B4A 27C5 F799 A681 3C11 D0D8 C2E8
>
>
> ________________________________________________________________
> Reply to this thread at ixda.org
> http://www.ixda.org/discuss?post=40458
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

25 Mar 2009 - 9:08am
Phillip Hunter
2006

That's sickening.

25 Mar 2009 - 9:14am
Dana Chisnell
2008

Here's a picture of the interaction for the iVotronic on the ballot
summary/review step.

http://www.flickr.com/photos/danachisnell/493697218/in/photostream/

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
Dana Chisnell
desk: 415.392.0776
mobile: 415.519.1148

dana AT usabilityworks DOT net

www.usabilityworks.net
http://usabilitytestinghowto.blogspot.com/

On Mar 25, 2009, at 6:35 AM, j.eric townsend wrote:

> The entire article is worth reading (and has actual hot links), but
> I'll
> call out how the design failure(?) was exploited by pollworkers to
> change votes:
>
> <http://www.crypto.com/blog/vote_fraud_in_kentucky/>
>
> [...]
>
> The Kentucky officials are accused of taking advantage of a somewhat
> confusing aspect of the way the iVotronic interface was implemented.
> In particular, the behavior (as described in the indictment)
> of the version of the iVotronic used in Clay County
> apparently differs a bit from the behavior described in ES&amp;S's
> standard
> <a href="http://www.essvote.com/HTML/docs/iVotronic.pdf">instruction
> sheet
> for voters [pdf - see page 2]</a>.
> A <a href="http://www.essvote.com/HTML/iVotronicDemo1/
> demo.html">flash-based
> iVotronic demo available from ES&amp;S here</a> shows the same
> procedure, with the VOTE button as the last step. But evidently
> there's another version of the iVotronic
> interface in which
> pressing the VOTE button is only the <em>second to last</em> step. In
> those machines, pressing VOTE invokes an extra "confirmation" screen.
> The vote is only actually finalized after a "confirm vote" box is
> touched
> on that screen. (A different flash demo that shows this behavior
> with the
> version of the iVotronic equipped with a printer is available from
> ES&amp;S
>
> <a href="http://www.essvote.com/HTML/iVotronicDemo2/
> index.html">here</a>).
> So the iVotronic VOTE button doesn't necessarily work the way a
> voter who read the standard instructions might expect it to.
> <p>
> The indictment describes a conspiracy to exploit this ambiguity in
> the iVotronic user interface by having pollworkers systematically
> (and incorrectly) tell voters that pressing
> the VOTE button is the last step. When a misled voter would leave the
> machine with the extra "confirm vote" screen still displayed, a
> pollworker
> would quietly "correct" the not-yet-finalized ballot before casting
> it.
> It's a pretty elegant attack, exploiting
> little more than a poorly designed, ambiguous user interface, printed
> instructions that conflict with actual machine behavior, and public
> unfamiliarity with equipment that most citizens use at most once or
> twice
> each year. And once done,
> it leaves behind little forensic evidence to expose the deed.
>
> [...]
>
>
>
>
> --
> J. Eric "jet" Townsend, CMU Master of Tangible Interaction Design '09
>
> design: www.allartburns.org; hacking: www.flatline.net; HF: KG6ZVQ
> PGP: 0xD0D8C2E8 AC9B 0A23 C61A 1B4A 27C5 F799 A681 3C11 D0D8 C2E8
>
>
> ________________________________________________________________
> Reply to this thread at ixda.org
> http://www.ixda.org/discuss?post=40458
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

25 Mar 2009 - 12:53pm
Den Serras
2009

I'm curious, how many of you Ix designers actually work with, hire,
or consult with security experts before finishing a project? Of
course this wasn't even a high-tech attack but the equivalent of
telling the voters to use pencils and then erasing them. Does anyone
even have a user testing program that includes people trying to f*ck
with the system?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=40458

25 Mar 2009 - 1:03pm
DrWex
2006

On Wed, Mar 25, 2009 at 6:53 AM, Den Serras <dennitzio at yahoo.com> wrote:
> I'm curious, how many of you Ix designers actually work with, hire,
> or consult with security experts before finishing a project?

I work on financial services software. You better believe we try to
figure out ways attackers would compromise our systems.

But outside of this domain, no, I don't think people have the proper
level of paranoia. Witness the recent Facebook-based infections.

InfoWorld had a note earlier this month about a simulated Twitter
attack vector (http://www.infoworld.com/article/09/03/20/Researchers_make_wormy_Twitter_attack_1.html).
I'm sure we'll see one of these in the wild before the year is out.

Best,
--Alan

25 Mar 2009 - 2:14pm
jet
2008

Speaking as someone who has done security in consumer electronics for
10+ years, I've never been asked by any sort of designer to be involved
in the design process. It's usually the case that engineering receives
the requirements docs, then I go through those and start looking for
problems.

One of the things I hope to achieve by going back to design school is
learning not only design, but how to talk to designers in their language
for those instances where I'm "just the engineer" on a project.

Den Serras wrote:
> I'm curious, how many of you Ix designers actually work with, hire,
> or consult with security experts before finishing a project? Of
> course this wasn't even a high-tech attack but the equivalent of
> telling the voters to use pencils and then erasing them. Does anyone
> even have a user testing program that includes people trying to f*ck
> with the system?
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=40458
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

--
J. Eric "jet" Townsend, CMU Master of Tangible Interaction Design '09

design: www.allartburns.org; hacking: www.flatline.net; HF: KG6ZVQ
PGP: 0xD0D8C2E8 AC9B 0A23 C61A 1B4A 27C5 F799 A681 3C11 D0D8 C2E8

25 Mar 2009 - 3:43pm
Angel Marquez
2008

http://www.shunra.com/

25 Mar 2009 - 4:36pm
Den Serras
2009

We have to deal with security when we use a captcha or passwords, but
I feel like a lot of designers I know assume that, if there's a
weakness, it will be in the programming and so not their problem. But
this is a case where the exploit absolutely is in the user
interaction.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=40458

Syndicate content Get the feed