Site Meter

Bad Idea, in Voting

You may also like...

6 Responses

  1. A.J. Sutter says:

    You’re right, of course. Nonetheless, the analogy between banking and voting sadly rings true in other ways, these days.

  2. Paul Horwitz says:

    I appreciate the concerns and have no particular stake in this debate. But I wonder two things: 1) Isn’t this, like any other choice of policy instrument, simply subject to cost-benefit analysis, in this case balancing the risk of catastrophic harm against the smaller but potentially more certain risks of the current system? 2) What is the actual experience in, eg, Estonia and Switzerland? Have there been costs and harms? Have there been benefits?

  3. Danielle Citron says:

    Great to hear from you both, and A.J., look forward to hearing about your book project. For Paul’s question, the question of cost-benefits is worse than what I portrayed. The federal government post HAVA spent millions upon millions for the states to buy DREs, which have their serious flaws but certainly pose less security risks than Internet voting. So the notion of throwing those out (and states like NY just sunk their fiscal teeth into them as Maryland did just a few years ago buying all new ones) for a less secure option shows that the cost of switching is higher for little benefits (people may vote more but then again their intended votes will be more likely to be switched, flipped, or not counted due to malware, DDOS attacks, etc.) So seriously why would we think about it? Because election officials love shiny new ideas and are not technologists. There are far more odious reasons too.

    All from me, back to the book (and also an essay with David Gray)!

  4. Ken Rhodes says:

    In re Paul’s question/suggestion, we would have to establish the “cost” of a stolen election, the “cost” of compromising the secrecy of the ballots, and the “cost” of a denial-of-service attack that caused many people who expected to be able to use the system, and thus did not make alternative arrangements, to lose their opportunity to vote.

    We don’t generally do cost/benefit assessments on the rights guaranteed us in the Constitution. The “right” to elect our government would seem to me to be subject to a similar consideration.

  5. Paul Horwitz says:

    With all due respect to Ken, I think cost/benefit assessments are a regular, if constrained, part of constitutional rights adjudication–both in constitutional systems that expressly contemplate proportionality analysis and in those, like ours, in which it is not explicitly set out in the constitutional text but happens just the same. And just as we should consider the costs Ken sets out–which are among the very costs I had in mind–we should also consider any potential benefits, including increased voting rates (if, that is, one thinks higher voting rates are a good thing), reductions in lower-level fraud and error, and so on. Again, I’m not for or against it, and I’m fine with Burkean conservatism on this point, and on any other issues on which Danielle wants to be a Burkean conservative! Just asking the questions. I’m still especially interested in the experience of those nations that have actually gone this way, but that’s by way of curiosity, not advocacy of a particular result.

  6. The question isn’t as simple as cost-benefit, because we can’t say “if you spend $X more you reap Y benefit”. (Defining Y, though not easy, is probably feasible, if you try to use something like the percentage of votes that are cast accurately, plus allowances for who will cast a vote.) The problem is that we don’t — and, I think, can’t — have a good handle on the trade-off for elections. Note that the tradeoff exists even without computer issues; better-trained poll workers could make a big difference, as can things like avoiding butterfly ballots. But elections are already costly, and counties are strapped for money. Beyond that, we don’t have a good handle on the extrema; the worst case scenario with computerized voting systems is far worse than with manual systems.

    Computerization makes it worse for two reasons. First, there’s the security issue: can someone hack the voting system? There have been plenty of lab studies, but to my knowledge at most one fraud case tied to DRE (Direct Recording Electronic) voting machines. However, if you care about the subject see the many reports that were part of California’s “Top to Bottom” review; http://www.sos.ca.gov/voting-systems/oversight/ttbr/red-overview.pdf is a good starting point.

    Personally, I worry more about bugs. Code is hard to get right; voting machines are very hard, because of the voter privacy requirement: it means that one can’t keep adequate log files. There have been many reports of buggy code; see, for example, Ed Felten’s hard evidence of results that just can’t happen. These are far from the only ones; one notable one occurred in North Carolina because election officials ran far more votes through a machine than it was designed for — somehow (and the programmer’s logic escapes me; it was much harder to do it this way), not enough digits (actually, binary bits) was allocated to hold the total, so many votes were lost. (My own comments are in my blog; see especially the link to the article on Bernalillo County, New Mexico, in 2000 — a far more interesting, though less reported, story than Florida.)

    I think the best way to understand the problem is to realize that virtually no computer scientists think it’s a good ida. Normally, people push their own field’s products; here, you see the opposite.

    Could a really reliable electronic voting machine be developed? I’m extremely skeptical. I can say that doing so would be extremely expensive; we know that from the cost of developing other ultra-high-reliability systems (aircraft flight control computers, phone switches, etc.). We also know (see Avi Rubin’s paper on Diebold software) that production systems are not developed with that level of care. You get at most what you paid for, and I’m not sure one can pay enough here to get a system where the worst-case result is acceptable.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

*
To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Anti-spam image