Whatever voting technology is chosen, it needs to be open source, both software and hardware.
On Mon, May 4, 2020 at 8:52 PM Jon Zingale <jonzing...@gmail.com> wrote: > Cody, > > I'm inspired to contribute some thoughts to yours. I feel that > whatever *fix* is imagined for voting, we should be prepared to > adopt it for a long time. The process of testing out new voting > schemes may take a few administrative cycles and may become > vulnerable to manipulation or degradation as the *concrete dries*. > I can see value in putting time limits on the experiment and taking > measures to protect this experiment from tampering by any given > administration. Precedence set by changing something as foundational > as voting demands careful thought. If voting systems be allowed to > change with fashion there will be vulnerabilities introduced, perhaps > similar or worse than the exploitations we are seeing in almost every > other aspect of government. To be fair, the present voting scheme already > appears corrupt or out-of-spec from my point of view. I do think it is our > responsibility to think about this problem. > > Secondly, I would like to contribute some thoughts on the topic of > remote voting. Perhaps rather than solving the app based voting > issue perfectly, we could aim at having certainty for validating > votes that is better than already exists. It may be the case that > under a *phone app* voting system, we still end up with voters in > Florida that have been known dead for a decade. If we can assess > what the present error bars are then we can have a goal in mind. > > There are certainly many truly good thoughts on cryptography > and as Neal Koblitz has pointed out in a bold non-paper paper > <https://eprint.iacr.org/2015/1018.pdf>, > one of the functions of the NSA is to act as consultants on cryptographic > practice. For our entertainment, let's imagine a collaboration between the > NSA and some large gaming company, Blizzard perhaps, where the goal is > to develop a *critical application* voting app. While I anticipate > aggressive > objections from some friam readers, there is something worth thinking > about. > A friend of mine pointed out that when classic World of Warcraft was > recently > released, Blizzard was prepared to have over 500,000 simultaneous users. > These users are not making 15 one-time choices but rather orders of > magnitude > more choices. These choices are handled fairly consistently, with few > dropped > packets and with little lag (each of which is demanded by the online gaming > community). This suggests to me that there *are *industries, like the > gaming industry, > that have thought very carefully and for a long time about the problems of > large > scale concurrent user bases and verification of its user base. Surely the > tech is > out there, but I am unsure what the next careful steps ought to be. > > Cheers, > Jonathan Zingale > .-. .- -. -.. --- -- -..-. -.. --- - ... -..-. .- -. -.. -..-. -.. .- ... > .... . ... > FRIAM Applied Complexity Group listserv > Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam > unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com > archives: http://friam.471366.n2.nabble.com/ > FRIAM-COMIC http://friam-comic.blogspot.com/ >
.-. .- -. -.. --- -- -..-. -.. --- - ... -..-. .- -. -.. -..-. -.. .- ... .... . ... FRIAM Applied Complexity Group listserv Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com archives: http://friam.471366.n2.nabble.com/ FRIAM-COMIC http://friam-comic.blogspot.com/
