On page 13 of my “Risk-Limiting Audit Implementation Workbook”, I present a possible solution for conducting a ballot-level comparison audit on ballots scanned in a polling location. Experts argue that this solution still allows the voting system to cheat. I would love to kick off a discussion of other possible solutions and why this problem merits finding a solution.
For convenience, here’s the text I think you’re referring to for dealing with the complications around matching CVRs to paper ballots with precinct scanners:
Fitting scanners with mechanical imprinters.
Printing a nonsequential CVR number, assigned by the voting system, to each ballot sheet.
Creating a ballot manifest identifying the scanner name, box/bag number, number of ballots in each box, and seal or container ID.
Randomly selecting ballots from the ballot manifest using the random sampling techniques previously described.
Determining that the list of ballots to be retrieved indicates each ballot’s sequential location within a specific batch.
Requiring the audit board to count down or use a scale to find the specific ballot (as done in a ballot-polling audit).
Modifying the audit tool to allow the audit board to input the imprinted CVR number tying the ballot back to the CVR record for a ballot-level comparison audit.
I think it’s important to note that the imprinting has to be integrated with the scanning, so that the CVR includes the imprinted id. Otherwise it is very hard to match the ballots up.
Note that I don’t think it is necessary for the id to appear on the image of the ballot, since we don’t use the images in the audit. But it would be nice if they did, since that would make it easier to target ballots for auditing etc.
Also note that the imprinting should be done after the scanner has accepted the ballot as being cast. If the scanner determines that there is an overvote or other error with the ballot, and gives it back to the voter, it shouldn’t print anything on the ballot.
I think the missing piece in this audit plan is that it is important for the audit to somehow protect against mismatches between the imprinted ids and the ids in the CVR file. Remember that we don’t trust the CVRs. E.g. the audit could somehow ensure that there is a 1-1 mapping between the imprinted ids on the paper and the imprinted ids in the CVRs (and it isn’t immediately clear how to do so efficiently).
Otherwise, imagine this simple, contrived attack scenario:
One contest, yes/no referrendum.
Manifest lists 3 ballots in the batch
Hacker wants to show a “No” result (2-1), despite paper documenting a “Yes” result (2-1).
The 3 CVRs have imprinted ids and votes like this. They indicate a win for “No” as desired:
- 910 No
- 032 No
- 342 Yes
The paper ballot ids and votes are like this, providing evidence that “Yes” actually won. Note that id 342 is reused (and maps each time to a matching CVR, so the audit will work out fine no matter which ballot is chosen), and id 032 never shows up:
- 342 Yes
- 342 Yes
- 032 No
A simplistic audit would only catch this if it happened to select two paper ballots with the same imprinted id.
@nealmcb can you say more about how imprinting can be done “after the scanner has accepted the ballot as being cast”?
There is a point in time when a ballot has been scanned, interpreted, and “cast”, after which it will never go back to the user. I’m thinking that the imprinting should happen after that point in time. Otherwise, if the system alerts the voter that they have an undervote, and they want to get the ballot back to correct that, and submit it again, you would end up with multiple imprints on a single ballot.
If that sort of undervotes fixing is not supported, and if all rejections (e.g. for overvotes) require the voter to get a new ballot, this might not be a problem. But it has come up multiple times in past discussions, and I thought the usual recommended model was to only imprint after final acceptance.
But perhaps you could have a model where the scanner does imprint earlier, and afterwards simply rejects ballots that already have an imprint. That would mean that a voter couldn’t fix undervotes without getting a new ballot.
I couldn’t agree more about imprinting after final acceptance. I know first-hand how confusing it can be to have multiple imprints on a ballot when you’re conducting a ballot-comparison audit. My question was more to understand how the technology would work for voting equipment to scan, interpret the image/data, receive voter feedback (if the ballot is rejected) and still imprint in a designated location on the ballot. I think I need to get better acquainted with the current precinct scanners and how they function before I can comment further.
I’m no scanner expert, so I am also eager to hear from people who know better how existing scanners might be adapted to handle this, what the implications might be, and creative new ideas for how to best handle this critical unmet need!
regarding #3 it is my understanding that the ballot manifest should be able to be produced before knowing the scanner identity when post-cast scanning is used ( central count, remote voting, transitive audit CVR capture.)
Note also that in central count scenarios it is possible to imprint prior to scanning for tabulation, as Denver does. The process involves sampling from the list of ballot images and looking up the imprint number within the image, manually, to confirm the correct ballot pull. However this suggests that the ballot manifest is created during tabulation and that violates the principle that we are not trusting but instead auditing the voting system accounting. Another reminder that the ballot manifest used for sampling should be created prior to knowledge of the scanner ID.
Completely agree @harvie. I can see how #3 might give the impression the information is coming from the voting system. That was not my intention. If you look on page 14 of the Implementation Workbook (Part2), I’ve tried to stress that the information in the manifest should never come from the voting system. Generally, the information is recorded in the manifest after ballots have been scanned along with the unique batch number and total number of ballots - all recorded by the person processing the ballots, not from information provided by the voting system.
Glad to hear the recommendation is to create the manifest outside the voting system ( meaning tabulator or more specifically the scanner/ EMS combo.) The best practice is to create the manifest from which the RLA obtains its samples before tabulation and as early as possible after acceptance for counting in order to catch ( meaning allow sample of) ballots that for some reason do not reach the scanner at all. Interesting cases are: in person central count where acceptance is at the early polling center but scanning is days later, provisional where acceptance hasn’t happened yet but casting is complete, etc. The earlier the manifest is created ( including before knowing the scanner ID ) the more capable the RLA will be.
I realize this topic is voter facing scanners and this is a special case where acceptance immediately precedes tabulation. Still the manifest could arguably come from the check-in table rather than a post scan manual count. That way the RLA could recognize a fraudulent scanner that produces no CVR, but also it would sample ballots of fleeing voters ( and I think of this as better detected and perhaps written out of the manifest rather than ignored by RLA.)