% fortune -ae paul murphy

Evoting

Pkstephens, a regular talkback contributor who writes some very insightful stuff, responded to my earlier comments on evoting with a number of queries and, ultimately, a long discussion I thought made a compelling argument.

Here it is in its entirety:

I'm not necessarily disputing the elegance of the technical solution that Mr. Murphy is offering. I am saying that there are other concerns -- non technical -- concerns that reduce the overall value of his solution. In this case, those concerns are legal, moral, and philosophical.

But in a more general sense, the same basic criticism is valid for a wide range of proposed technology solutions. Technical elegance and brilliance are rarely the sole criteria, or even the most important criteria, we should use when evaluating a proposed technology solution.

In evaluating the best solution to an existing problem it's important to think in essentials -- what really matters most. But essentials are defined by the ~problem~ not the proposal.

So if I'm evaluating a new voting system, the essentials are political (democracy, local control, transparency, accountability, etc... ) and economic (cost, transparency and accountability in the bid and contract process).

New and emerging technology often offers new ways to reduce costs and increase essential value -- but we should be careful not to confuse technology with essential value. The network system Murphy lays out could be a great solution for a large state -- where there could be few legal or ideological obstacles to his proposal.

But it's a fundamental mistake to conflate utility in one context with utility in another context. Or to put it differently, the best solution for my problem isn't always the best solution for your problem.

Far, far, too often technology advocates drop context, ignore the differences between two distinct problems, and fail to think in essentials. It's as true in a discussion over evoting systems as it is over whether a given entity should use MS Windows, Unix, Linux, or Apple.

One size does not fit all. There is no same best solution for every problem.

To all of which my only rebuttal is: "Yes, but in the United States (and Canada and Great Britain) everybody has the same basic problems: figuring out who gets to vote, making the opportunity to vote available only to eligible voters, and counting the votes afterwards. In other words he's right, one size does not fit all, but one architecture might because everybody has fundamentally the same problem.

Right now, of course, e-voting looks successful because the U.S. survived another round with minimal problems being reported - but I believe this is largely because the main stream press pretty much unanimously approves of the result. Consider, for example, a small sample of the headlines they were writing early on election day - i.e. before the results started coming in for their candidates:

Basically, I can't help but contrast the behaviour of Republicans like Allen facing narrow loses with that of the Democrats who lost in 2004 - remember something like 361 allegations of electoral impropriety made it to court in that go round, almost all of them filed by or on behalf of Democrats. In other words, I think that the quiet we're hearing right now with respect to e-voting is the sound of satisfaction that the right side won, not an indication that e-voting has become successful or trusted and the silence is therefore every bit as dishonest as the pre-emptive attempts to discredit e-voting outcomes that were being circulated prior to the election.

So with that in mind let me re-iterate the essentials of my proposal on fixing all of this before the 2008 round.

  1. As Stephens says, local control is a paramount consideration. I had this mind, but just to be clear lets re-iterate the fundamental Unix idea of combining centralised processing with decentralised control - i.e. it's a requirement that each jurisdiction, state or county, maintains control over its own processes and data, but that doesn't mean we can't do the obvious: standardise processes and systems across all jurisdictions.

  2. Voter lists are the primary source of pre-election complexities. Thus the proposal is to generate voter lists by jurisdiction (state, county, etc) as subsets of a national list itself generated from well maintained, mostly state or local government controlled, public information repositories such as tax rolls and licensing files.

    Basically the data and voting standards remain local, but people can't vote the full ballot in both Florida and New York.

  3. Existing voting machines are high cost, high complexity, and heir to fundamental flaws. In particular I believe that it's impossible to provide an audit trail for voting carried out on locally programmable, stand-alone, machines without giving up ballot secrecy.

    In response I propose:

  4. allow voting, by any qualified voter from anywhere in the country or its embassies and bases abroad, by ballot item. In other words, Joe voter could go in to a local school, identify himself, and vote for president - then go to work for the morning, and stop in a voting place near his place of work to vote on a proposition or for governor during lunch - and go a third time somewhere else on his way home.

    Why? because giving people the option of voting early and often provides an important protection against localised failure -and doesn't have any real cost to the system as long as enough polling places are open to prevent lines from building.

There would be some minor exceptions - places with no network connection - but for most jurisdictions this solution bypasses all the big problems: including registration and getting the voter to the machine he's registered to vote at, managing high volume advance and absentee voting, and protecting the system against threats like hacking and machine, data, or component theft.

Cheating wouldn't be impossible, of course, but the system would be so simple that it would be extremely hard to affect vote counts and harder yet to avoid detection during the post election audits.

And the total cost? I'll look at this in detail as soon as I can, but if you pay for the machines through school or other uses, the net incremental cost for a national or local election, counting registration and reporting, would probably come to less than 1% of current costs.

Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.