[FRIAM] Curmudgeons Unite!

[uǝlƃ ↙↙↙]

The only plausible answer to this is the acceptance of a satisficing rule, a tolerance for error/uncertainty. That's what allows us to trust the USPS, which is simultaneously cursed by individuals on a regular basis, yet one of the most trusted institutions in place. All this election integrity hooha centers around quantitative confidence and perfection.

But our first past the post system consistently tightens up our *intolerance* for uncertainty/error. That's the change that needs to be made first. As long as our elections are winner-takes-all and based on 50/50 thresholds, technology can't help us. Technology will simply kick the can down the road, leaving the main problem unaddressed. I.e. your billion dollar projects will largely be a waste of money, perhaps resulting in a Star Wars quality spinoff machine, but not solving the targeted objective.

The first actionable steps are being taken. Ranked choice voting is steadily being adopted. It's also *not* a panacea. But at least it targets the disease, rather than the symptoms.

On 8/19/20 10:06 PM, jon zingale wrote:
> Eric,
> 
> Yes, what are the next actionable steps? In an upstream post I wrote:
> 
> "Maybe a little flippantly and without dragging this entire post into design
> details, the voting app needs little more than a Facebook like-button, a
> Redis
> server, authentication, and a light-weight rest API. If the idea were to be
> taken
> seriously, such an app could be written starting now for an election in four
> years. It could be tested and verified by a trusted agency, like the NSA."
> 
> While the preceding quote effectively gets at the idea, I will further spill
> e-ink in the hopes of saying something practical, but first... Given the
> power
> to do so, I might try redirecting a hundred billion dollars from next year's
> military budget towards collaboration between big tech and government. The
> acceptance criteria would include public access to the code and the platform
> would be subjected to a week-long national hack-a-thon, complete with
> outrageous
> prizes and awards. Since this fantasy risks getting to far-out, let me reel
> things
> back a bit.
> 
> Let me begin with a mission statement: Our goal is to introduce a trusted,
> reliable and secure digital voting option for U.S. elections. Determining a
> metric for success will require identifying: the scale of the project (city,
> state, nation)[1], collaborators with diverse skill sets and talents[2], the
> strengths and weaknesses of the current voting options[3], the
> state-of-the-art
> for digital application design[4].
> 
> [1] Selecting an appropriate scale for the project will be crucial to the
> adoption of the application. A full-blown application backed by industry and
> government organizations (with lobbyists in D.C.) could easily find adoption
> at
> the national level. Since the sole collaborators maybe just you and I, we
> may
> wish to start small, targeting the city level. Planning for this latter
> case, let's
> be prepared to scale if excitement around the program builds. Perhaps
> borrowing
> from or explicitly using a crowd-sourcing model would be good, extending to
> the
> state or national level manifesting as explicit *stretch goals*. Getting one
> or
> a few city contracts for our application may be just profitable enough to
> bootstrap the process.
> 
> [2] The program will benefit greatly from the help of a diverse talent pool.
> We will need to design, build, test, and maintain the application. I
> advocate
> for seeking out individuals versed in building scalable critical
> applications
> and encouraging a transparent open-source development process. I foresee a
> role
> for trolls and white-hat hackers as it will be important to stress test and
> subject the application to *our worst*. We will need philosophers, critics,
> and
> trouble-finders all along the development process. That said, impossibility
> *proofs* ought to be taken with a grain of salt. We will need to lobby,
> campaign,
> and rouse excitement for the adoption of our application. It would be good
> to
> inspire competition because another group may just do it better, and
> ultimately
> this is what we want. It will be good to attract individuals that have a
> history
> with and have succeeded in: affecting policy, building grassroots movements,
> and
> selling the moon. It might be good to work with a business incubator or
> apply for
> an SBIR grant.
> 
> [3] You don’t have to run faster than the bear to get away. You just have to
> run
> faster than the guy next to you. By studying the integrity of the voting
> systems
> presently in use, we can know where to set the bar for success. For
> instance,
> that the meaning of the postal service is being over-loaded in the 2020
> election
> strikes me as a notable risk and a potential point of failure. Our
> application
> should be expected to do *just one thing*, and ideally the projects future
> funding will be promised independent of political influence.
> 
> [4] As mentioned in the upstream posts, large scale web-based applications
> are
> here: the FBI-Apple encryption dispute, 20M concurrent Steam users, 1-click
> shopping, etc... Our application doesn't need to be very fancy and it would
> be
> good to avoid failing like the Iowa caucus. We don't need a *big reveal* on
> election night and then to impress the world as it flies along flawlessly.
> The
> opposite is needed. By the time the application is in production, it should
> be
> road-worn and rugged, the code probed and debated thoroughly on stack
> overflow
> and subreddits. This will not be the time or place for proprietary and
> opaque
> black boxes. The tech can be as impenetrable as an iPhone, as packet hungry
> as
> a Steam server and as intuitive as drunk shopping at 2 am on Amazon. The
> time
> period allowed the application should mimic mail-in voting rather than the
> polls.
> Votes could be validated slowly if need be. Perhaps, this may be one of the
> only
> reasonable applications for a block-chain protocol?
> 
> Jon


-- 
↙↙↙ uǝlƃ