I’ve decided that there is a new career I should get into: software development for political committees, especially Democrats. It seems like an easy and rather a lucrative gig.
The most recent demonstration is the — well, I’m told I may not use the obvious metaphor involving the display of excrement, nor the more colorful phrase relating to sexual congress in clusters, so let’s just call it an “iowa caucus,” hope that becomes a new idiom for a complete cock-up, and go on.
As I’m sure most everyone is aware at this point, the Iowa Caucus became a complete iowa caucus when the smartphone app that was specially developed for the Democratic-ish National Committee failed. Spectacularly. With no recovery plan and no fallback approach. So now, it’s a day later and they hope to have partial results out shortly.
I’m a big proponent of the notion that programming is in fact hard and the skills involved are something that takes time to learn. (If you’re interested, I’m available to teach them.) But this application was not exactly rocket science.
Let’s think about this for a minute. There are 1681 precincts in the state of Iowa, according to Wikipedia. There are four candidates. So, each precinct needs to report 4 relatively small numbers.
Notice also that this only has to work once.
So, here’s a scheme.
First, build a tiny little web/phone app. Really tiny, honestly: it has a landing page, a way to log in for your precinct, and a place to report delegates for each candidate.
Security is an issue, but — in computer security, we talk about an “attack surface”. This app only needs to be active for about 24 hours, in theory. The attack surface is whether you can attack the authentication, and whether you can update the database without authentication. It literally needs do nothing else.
They apparently tried to be real slick with this. In Vice’s story on the app, they explain
in order to report the results, [the user] had to sign in with an email and password, provide a two-factor authentication, and enter a one-time password generated by the Google Authenticator app. After this, he would need to enter his precinct PIN, but he did not get that far… .
This is stronger than most bank apps; it should have been great.
In fact, though, this resulted in an error page "idp-caucus-2020. Oops!, something went wrong." A little further along, it reports the problem is an “unknown protocol” the browser doesn’t recognize.
Maybe it was a little too great. Security features that don’t work are secure but you don’t get anything done. This process was complex, had many many components — and failed.
This is truly a complete iowa caucus.
I often teach “bootcamps” for web development. As a pure web application, it’s a few dozen lines of code; and a phone application it’s a little more because you have to deal with two platforms, but only a little more.
This, as an application, is something I’d expect a bootcamp graduate to be able to build in a long afternoon; less than that if they don’t have to choose the platform first.
So, you ask, what happened?
Okay, this is just a guess, but my first guess is that they wanted to be impressive and cool and make users go “ooh” and “ah”. So they spent time and money on graphics — which frankly don’t look that impressive, but I’m sure you could make it a $10,000 design contract if you were spending someone else’s money on your friends.
Second, it’s clear that they literally did not test the software. There is no way they could be having that kind of problems with the authentication in production if they had tried the damn app first.
What they should have done is tested.
Maybe have a trial run a week before, where everyone logs in with test credentials and reports pre-defined test numbers. Have penetration tests — pen tests — at the same time. If you were building a real system, meant to take a substantial load over a long time, you’d do load tests, but in this case we know exactly what the load should be: 1681 sessions total. Ever. Over the course of maybe an hour as different precincts report. You can get fancy and do some capacity planning. A cocktail napkin would probably suffice.
On Caucus day, you distribute the real login credentials.
Then, for audit purposes, you have a sheet of paper with the same numbers, hand written, preferably legibly. You text a photo of the paper to a known number, and then deliver the paper by hand to a trusted location.
Of course, you could just do that, but how cool would that be? And, to be fair, doing it electronically should protect you from human tabulation errors.
On the “back end” — where these messages are received — you have an utterly simple database with a row for each precinct and four columns for the candidates. And notice, this is only 1681 rows. The infrastructure to do this is trivial. You could literally do it in the free tier on Airtable.
But they didn’t. They just didn’t.
I hope the DNC thinks it got its money’s worth.