dsernst
commented
3 months ago Copied from https://github.com/npfoss/nap-app/issues/6#issuecomment-2227161202
Implementation notes for self:
First, election admin enables by adding:
"randomize_order": trueto ballot schema, per question.
Documentation
Doesn't need to be programmed into Ballot-Design Wizard for now
- [x] ...but, would be nice to document under Schema Text Editor -> Advanced Features.
MVP v1 Design:
- [x] If item has
randomize_order: true, then on page load on voter's device, generate permutation array (shuffle) for rendering the options. Keep write-ins last.
Quick and dirty, but should work.
Slight cons:
- Since it happens on the client, every time they refresh the page, they'll see a new order. Maybe disorienting? Could store something more persistent to maintain the order through refreshes.
- Possible that lots of voters happen to draw similar orders? So just by luck of the draw certain candidates may get a slight edge over others? Unclear how much of an effect this is, though. And every candidate has an equal chance of it, so still more fair a priori than not randomizing.
- Maybe interesting if there was some way to more evenly balance this out? But not obvious how, without certain privacy compromises.
- Say we did store the generated permutation arrays, to help analyze effect sizes after the fact. Or even better, pre-assigned them for each voter so they're fairly distributed (all candidates would get a similar distribution at different orders). A corollary to the question about effect size is, "how much of hint does knowing a particular voter's rendered order give you about which of the anonymized votes came from them?" If it has little effect, there's little privacy implication, but then why bother recording anyway? If it has a large effect, that's interesting, more reason to nudge people towards randomizing, but then the privacy implications are more important too.
More Advanced v2 Design, to solve almost all of these problems
Instead of generating the permutation array from new random bits, generate it deterministically from a seed of hash(verification_number + question.id).
Benefits:
- Still unique per user, since
verification_numberis random among 10^12 possibilities.question.idisn't strictly necessary, but it means the permutations will be uncorrelated across multiple questions too (which seems a bit better), sincequestion.ids are forced unique.
- The user-specific ordering will now persist through refreshes, since
verification_numberis kept in localStorage (solving Slight Con 1 above). - Will allow deterministically re-generating the order each decrypted vote saw, since verification numbers are published after anonymization. So this enables analysis to measure correlation between rendered-order on page and effect on selection. But all privacy-protecting, because no new data stored touching anything tied to identities.
- Bit more verifiable for others to check. Nicely preserves compatibility if we later implement hashing & encrypting the ballot design presented to voters, as we've sketched out previously.
Cons?
- Tad more complex to implement than the MVP Design above.
- [ ] Need to write the
permutationFromSeed()function. Have similar already. - [ ] Currently, verification numbers don't get generated until voter makes their first selection. Will need to move to initial page load.
- [ ] Need to write the
-
- [ ] Need to ensure it's still plenty fast. Guessing it should still be imperceptible, but would be good to confirm with measured data.
- Doesn't address the potential bad roll for certain candidates. On the flip side, does let us see now if/when that's ever happening, and measure the effect size, all privacy-preserving. And in any case this remains a priori fair. And it's really more of an issue with small # of voters. At large scales (more important elections), the law of large numbers should result in much closer to even distributions.
See https://github.com/npfoss/nap-app/issues/6
————