scan: reduce likelihood of accepting two sheets with "page key"

[eventualbuddha]

Per @mcchilders:

include a "page key" or something in the QR code that is definitely not unique enough to ID ballots, but is unique enough that your chances of finding a front of one ballot and a back of another that have the same one is pretty small, then check that?

My reply:

could just have 0-9 or a-z tacked onto it so there are N different versions of the same QR code

Slack discussion: https://votingworks.slack.com/archives/CJU9MSC6S/p1633972742026700

[benadida]

Initially I said I loved this, and then I realized I may not have understood the full proposal, so a few thoughts/questions in no particular order:

• for this to be valuable, it means we have to not print large batches from a single PDF. Is that something we're willing to do? Or do we think that if we're just doing this for a few different "page keys", so it's just a slightly more complex print job?
• are we trying to prevent errors, or some level of malicious attempts?
• specifically what's the scenario we're trying to prevent, maybe the use of the precinct scanner by an EO to scan a whole bunch of ballots that mistakenly feeds two ballots at once? Something else?

[mcchilders]

In line:

• for this to be valuable, it means we have to not print large batches from a single PDF. Is that something we're willing to do? Or do we think that if we're just doing this for a few different "page keys", so it's just a slightly more complex print job?
  • I was imagining we would do it only for BMD ballots, but either/both would be a valuable improvement, just at different scales.
• are we trying to prevent errors, or some level of malicious attempts?
  • Just errors
• specifically what's the scenario we're trying to prevent, maybe the use of the precinct scanner by an EO to scan a whole bunch of ballots that mistakenly feeds two ballots at once? Something else?
  • The use-case that was listed in the thread in the channel: "I inserted two ballots at the same time into precinct scanner and it accepted both on a single pass presumably only counting the top one, unless it has x-ray vision"

On Mon, Oct 11, 2021 at 4:59 PM Ben Adida @.***> wrote:

Initially I said I loved this, and then I realized I may not have understood the full proposal, so a few thoughts/questions in no particular order:

• for this to be valuable, it means we have to not print large batches from a single PDF. Is that something we're willing to do? Or do we think that if we're just doing this for a few different "page keys", so it's just a slightly more complex print job?
• are we trying to prevent errors, or some level of malicious attempts?
• specifically what's the scenario we're trying to prevent, maybe the use of the precinct scanner by an EO to scan a whole bunch of ballots that mistakenly feeds two ballots at once? Something else?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/votingworks/vxsuite/issues/993#issuecomment-940435512, or unsubscribe https://github.com/notifications/unsubscribe-auth/AL6NEJBYG73V6QDS2IMXTDLUGNF2HANCNFSM5FYXX5OA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Monica Childers Product Manager, VotingWorks (316) 680-3789 @.***

[benadida]

for BMD ballots, I think this is already handled, or at least it should be handlable without any change, since there should only be one side that has a QR code. My comments above were more for HMPB.

In terms of use case, I'm trying to understand when we think someone would insert two ballots specifically. For a voter, I can imagine the case mostly if they have a multi-card ballot, in which case we should already be able to handle that situation. Thus why I'm wondering if the use case we are considering here is that of an EO feeding multiple ballots into the precinct scanner, maybe the absentees at the end of the day or something, and going a little bit "too fast"? Or is there some other example of this problem I'm not thinking about?

[mcchilders]

Not that I know of - I'm not worried about a poll worker feeding multiple sheets into a precinct scanner (that never works on any precinct scanner, so there's no reason to expect that it would on ours, and they've all used other precinct scanners before.) It sounds like you're saying what Matt P described, a voter feeding both pages of a multi-page ballot into the precinct scanner is already handled? If that's the case then I don't think we need anything - how are we handling that right now, since it seems like that's news to everyone?!

On Mon, Oct 11, 2021 at 5:17 PM Ben Adida @.***> wrote:

for BMD ballots, I think this is already handled, or at least it should be handlable without any change, since there should only be one side that has a QR code. My comments above were more for HMPB.

In terms of use case, I'm trying to understand when we think someone would insert two ballots specifically. For a voter, I can imagine the case mostly if they have a multi-card ballot, in which case we should already be able to handle that situation. Thus why I'm wondering if the use case we are considering here is that of an EO feeding multiple ballots into the precinct scanner, maybe the absentees at the end of the day or something, and going a little bit "too fast"? Or is there some other example of this problem I'm not thinking about?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/votingworks/vxsuite/issues/993#issuecomment-940446184, or unsubscribe https://github.com/notifications/unsubscribe-auth/AL6NEJFWXNHKQDDKB6K6MCTUGNH5VANCNFSM5FYXX5OA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Monica Childers Product Manager, VotingWorks (316) 680-3789 @.***

[benadida]

Yes, correct, if a voter feeds two sheets of a multi-sheet HMBP ballot together, our current scanning approach will detect that and reject them, because those two sides are NOT expected to appear as a front-and-back pair.

Also, on a BMD ballot, the scanner expects only one side to have a QR code, and will reject the ballot if both sides do (or if the other side is an HMPB ballot page.)

However, if someone (voter/EO) feeds two sheets of a ballot, where the exposed top and exposed bottom correspond to a valid front and back of a particular sheet of a particular ballot style & precinct, then it will accept those two as one ballot. We can reduce the chance of that by requiring that the orientation match between top and bottom, but beyond that, currently, we can't do better.

I (possibly incorrectly) read your proposal as introducing some kind of extra identifier so that there is, in effect, more than one type of ballot for a given precinct and ballot style, thereby reducing even more the chance that two sheets stuck together would be accepted as one ballot. But, of course, that would complicate the printing process for those ballots if we really wanted to make use of that.

[benadida]

for HMPB ballots where this would be useful, this would complicate printing, so let's not do this.