The great Freakonom, Steven Levitt, argues that the market price of vote selling is effectively zero because of its essentially insignificant weighting in the outcome.

Of course I agree entirely with Ben Adida’s take: the price is effectively zero because the transaction cannot be verified as having been fulfilled.

The design of E2E receipts completely revolves around this idea, and we spend a lot of time on it. It’s also why E2E voting via the internet is such a hard nut to crack.How can you possibly enforce ballot secrecy in that environment? How can you even enforce it in a polling place?

There is another dimension to it that I wanted to talk about.

If you already have a law against vote selling, do you really need the additional enforcement mechanism (booths, envelopes, etc) at the polling place?

Many other criminal laws do not lean on an additional physical protection measure to prevent the crime; being caught and punished is enough.

There’s no particular physical measure preventing someone from robbing someone of $10 (the minimum bid of the ebay vote selling incident), presumably just the risk of a jail term.

Consider a related situation. In Canada (obviously where there is no HAVA) you can assist someone in voting as long as you sign a statutory declaration that you won’t tell anyone how that person voted. The idea being, yes, you could do it, but you have the legal incentive not to, especially that you’re on record. The Crown probably couldn’t even prove the offense in most situations. And yet this measure seems to be effective enough that no cases come to mind.

You can also (again via a statutory declaration) vote at a polling place without being on the voter list. Presumably you just could go around from poll to poll casting ballots. But it’s ultimately the ‘lawonomics’ — the cost of going to jail weighed against the benefit of stuffing 3 or 4 ballots — that seems to prevent this.

Last thursday I went to the First Open Workshop on the VVSG (FOW-VVSG). Audio of all the sessions are posted online, and I encourage anyone interested to check it out. It was a very interesting event, and I wanted to share some thoughts I had on two of the things that piqued my interest…

Verifiable vs. Verified

There was an interesting discussion of the meaning of the use of the word “Verified” vs. “Verifiable”. I have always thought verifiable was the proper term because it is optional if the voter actually does the verification and — even if they had done so — there still may be a chance that they did not succeed in verifying the printout, but it really depends on your perspective. Dr. Mercuri pointed out that, legally, when you press the OK button, you are certifying that what was printed is what you accept as the proper recording of your vote. In that sense, it is verified. It is unclear to me what term should be used in the VVSG. If your presentation is such that 1 in 5 voters will not catch a mistake on the record the machine makes, can you really call it verified?

Software Independence

Software Independence, or rather, the way it was presented in the proposed VVSG, turned out to be controversial, and I think it came up in discussion on a majority of the panels. Personally, while I think it is fine as a design approach, it was not appropriate to use the way it was used as part of the standard. In my opinion, it is similar to “build security in”, “default deny”, and “have many levels of security” — you want to do those things, but there’s no hard and fast way to check off in a box that someone did it. The way it is defined in the standard it should be called “Software Prohibition”, and not “Software Independence”. It prevents any software from acting in any meaningful way — and at the same time this definition is weak in some aspects.

Stefan pointed out that SI as defined in the VVSG was flawed on two levels. First, the definition was ambiguous, and second, the IVVR (the device they made up to say things were SI or not) does not meet the weakest definition of SI that he could come up with. His slides say it all, but I will elaborate. The VVSG defines SI as follows:

“…an undetected error or fault in the voting system’s software is not capable of causing an undetectable change in election results.”

The definition of SI is ambiguous because it does not say who can check the election results or when they can be checked. The VVSG is also missing audit mandates, so even if an error might be detectable, there is no guarantee that the software will not undetectably change the result anyway.

His explanation for why IVVR does not meet SI is unclear to me, but I will point out that VVPAT, which is supposedly SI, does not meet the definition. The reason is because not all voters check, or can check (specifically the visually impaired), the paper printout. All the DRE must do is incorrectly print out the paper. The voter, if he checks, thinks he made a mistake, and goes back to change his vote, then he presses submit again, and the machine prints out the correct choices this time. If he doesn’t check, the machine succeeds at undetectably changing election results. Careful readers might point out that this kind of error can be detected, but my point is that it might not be, or it might be a deliberate flaw that could be introduced on a per machine basis the day of the election. If you did everything you needed to do to detect all instances of this error you might be doing enough checking that even if you didn’t have VVPAT you could catch any errors introduced by the system. Wether the system is SI in this case depends on procedures, that is, if you check and what you check and how often you check to find errors. Of course, if you know exactly what the error does, then you could likely prevent changes in election results.

Dr. Yasinsac from SAIT also had some damning things to say. Among them being that anything that uses software can’t use it in a meaningful way and be software independent. He also popped the question “what are the security properties of paper?”, pointing out that the VVSG is asking for design and not performance requirements in this respect.

Later, Jim Dickson pointed out that the IVVR is not accessible to voters with disabilities. That it requires a “human readable” record I think makes it so that anything that is not printed paper cannot be an IVVR, even though the claim was tossed around that it not necessarily be a paper trail. I also don’t think OpScan or VVPAT meet SI requirements because if you don’t check 100% of the record, you can’t find the problems, and there’s no requirement that you do that kind of checking like there is in Scantegrity or Punchscan.

Other

There was much more that went on at the conference than what I’ve talked about here but unfortunately I don’t have the time to detail them here. The OVC, AADP, and EPIC all gave interesting talks that I encourage you to download and check out.

There was no consensus from the workshop. If you could say anything, the consensus was that all “schools of thought” represented at the meeting had problems with the document. The paper-trail people didn’t like it because of gaps in the document and things that it doesn’t address or define (e.g. “What is a ballot?”). The industry didn’t like it because it would make things too expensive (in particular, it requires use of a TPM-like chip that doesn’t exist). Crypto voting AND security people didn’t like it because SI was ambiguously defined. The disabilities folks didn’t like it because paper wasn’t accessible, and they didn’t like the layout of the accessibility requirements.

The NIST folks involved in the creation of the document and the EAC were both represented at the conference. They seemed to be taking the criticism well, and answered lots of questions. Overall, it was much more productive than I thought it would be. I will leave you with a choice quote from Jim Dickson (As best as I can remember it):

“We take people who are an average of 72 years old. We sleep deprive them for 2 days, and then we say ‘Now do the most important thing, be involved in counting the ballots!’. It’s a system that we know doesn’t work.”

Given a recent opinion piece in the Washington Post, we’ve been asked about what “we” think about the bill and this article. I can’t speak for the others, but here are my thoughts.

The system is sort of a hybrid, so wether the bill prevents the usage of Punchscan depends on the final definition of a paper record in the bill. There is a piece of paper the voter’s use but part of it is destroyed. If the part left over constitutes a paper record then it would probably be OK. However, if that’s not the case it would severely discourage the use of the technology, preventing use of possible federal funding and banning it in states with laws worded to only permit use of systems meeting federal criteria.

Despite what appears to be what some would call a seedy AEI affiliation and some factual errors, the article makes an excellent point — mandating a specific technology (which has been known to be problematic since the inception of voting) is a bad idea. By contrast, the authors of the bill could have taken the approach of Software Independence, where the outcome of an election can be determined independently of a piece of software. Any software independence approach would rule out paperless DREs, a hidden audit trail printout, and other ill-conceived technology. DREs with unreliable printers for a VVPAT approach could also be excluded, but you would need to add a reliability requirement (not hard to do). Our system, and similar systems like PAV, would more easily fit into such a definition.

After Rereading the bill, it is still unclear if the language would permit Punchscan, but even if it did that is clearly not the intention of the bill. Election officials are going to play it safe, so they aren’t going to take any chances if its ambiguous. Thus, I think that the mere intention of the bill will take Punchscan and other E2E systems off the table for election officials.

It appears to me that the bill’s creators didn’t bother consulting or listening to the people helping the TGDC (NIST?) or anyone among the community of researchers where this idea was well known, and this is disappointing as it seems like such an obvious thing to do.

An alternative approach that they could take is to add a provision for use of “experimental systems” — where they would be permitted to be used on a small scale if they met certain criteria (e.g. the blessing of the EAC). This would still allow for testing/use of a fundamentally new approach, and would solve the WaPo writer’s aircraft analogy he uses at the beginning of his piece.

I think that the effect for us, in the worst case, is that we’ll have to approach other countries to see if they might be interested in the system.